On Thu, May 29, 2014 at 11:04:35PM +0200, Jakub Wilk wrote: > Package: apt > Version: 1.0.3 > Severity: grave > Tags: security (personally, this feels a bit high. Mostly as deb-src isn't even part of many default configurations in which apt is found. And in those where you find it, you probably find also vcs checkouts and "wget | sh" … Anyway tl;dr: I wouldn't like to release jessie with it, so I leave it at that and we should ask the relevant security teams what they want, but I am too dreamy now to figure out a patch/all the mail addresses…) > I've been investigating how apt behaves when the repository doesn't contain > any Release signatures (possibly because they were stripped off by a > man-in-the-middle attacker). Thanks! Not many do, so such things usually never get reported… The pain of being even less sexy than OpenSSL… (may I ask to push security bugs through the security teams first though, so that they can coordinate properly as 'apt' and 'security' tends to make people super nervous as recovery tends to be painful) > This is what I found out: > > | # cat /etc/apt/sources.list > | deb http://ftp.debian.org/debian/ unstable main > | deb-src http://ftp.debian.org/debian/ unstable main > | > | # apt-get update > | Ign http://ftp.debian.org unstable InRelease > | Ign http://ftp.debian.org unstable Release.gpg > | Get:1 http://ftp.debian.org unstable Release [205 kB] > | Get:2 http://ftp.debian.org unstable/main Sources [7249 kB] > | Get:3 http://ftp.debian.org unstable/main amd64 Packages [6758 kB] > | Fetched 14.2 MB in 29s (479 kB/s) > | Reading package lists... Done > | > | # echo $? > | 0 > > Hmm. There is no warning suggesting that anything fishy is going on, and the > exit code indicates success. (Perhaps the "Ign"s could raise suspicion of an > observant sysadmin. But who knows what "Ign" exactly means? At least the > apt-get(1) manpage doesn't know.) Well, "Ign" isn't "Get" - and it stands for "Ignore", but that is surely not your point here. The "problem" is that apt supports unsigned repositories as too many people would bitch too much if it would require a signature – it used to work before apt 0.6, it has to work forever, man – FOR EVER! So not getting a signature isn't an error and not even fishy. It's absolutely fine… Maybe we could be "evil" and enforce the usage of the flag on update, too? > Fortunately, apt-get won't let you install anything: > > | # apt-get install -qq nyancat > | WARNING: The following packages cannot be authenticated! > | nyancat > | E: There are problems and -y was used without --force-yes > > And it won't let you even download binary packages: > > | $ apt-get download nyancat > | WARNING: The following packages cannot be authenticated! > | nyancat > | E: Some packages could not be authenticated JFTR: --allow-unauthenticated is the flag littered all over the place to let this error disappear. Similar to wget --no-check-certificate | sh. > So far, so good. However, apt-get happily downloads unauthenticated source > packages, with no warning: > > | $ apt-get source -d nyancat > | Reading package lists... Done > | Building dependency tree > | Reading state information... Done > | Selected version '1.2.2-1' (unstable) for nyancat > | Need to get 20.6 kB of source archives. > | Get:1 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (dsc) [1782 B] > | Get:2 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (tar) [14.1 kB] > | Get:3 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (diff) [4748 B] > | Fetched 20.6 kB in 0s (1838 kB/s) > | Download complete and in download only mode > | > | $ echo $? > | 0 Snipping the rest as if it downloads, everything else is just a follow up. You see btw that dpkg-source (which does the unpack/build) would check signatures on the dsc if it had them available. I think installing debian-keyring would help (at least for packages from debian). You will also notice that the check for the hashsum in the Sources, as well as the check for the hashsum of Sources in Release is done, you "just" don't get this lovely warning & error message for missing signatures (aka: the MITM has to be a bit more active in modifying these files as well to get away with sneaking bad files on your system). The source (is this a pun now?) has no indication of ever wanting to check this. Easy to add, for sure (CheckAuth method exists in various versions in various places). Hardest part will be deciding if a) sources should be interactive (needs a new string) OR b) not just like e.g. 'download'. I guess the later makes more sense (similar to download) and is more backward compatible (not suddenly interactive), would therefore not require a new string and should be simple(r) to backport if needed. As this will surely find at least a few complainers for stable I will repeat it though: This breaks (obviously) compatibility with unsigned archives. Workaround for those buggers would be the flag from above. Haven't written patch/testcase yet though, as I should be in dreamland for a while now, so I could be horribly wrong about all this of course. Not a lot of time tomorrow^Wtoday (and I can't upload anyway), so, Michael, could you please have a look and talk to the security teams? Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature