reopen 749795 stop Hi. I'm reopening this for now, even if the issue is solved from a technical point of view (see below why). In my opinion this is really some horrible bug... probably it could have been very easily found by others, and we have no idea whether it was exploited already or not. Anyone who believed in getting trusted sources might have been attacked with forged packages, and even the plain build of such package might have undermined users' security integrity. The same is the case with all debian build systems which probably rely on secure APT. So IMHO this bug definitely deserves a CVE and a DSA,... so that people are informed that there systems might have been compromised (i.e. if an attacker tricked them into using forged sources)... which is also why I reopen it. And do we need an investigation whether Debian an the Debian archives themselves might have been intruded that way? It's really saddening to see that such an issue could slip through, especially when I've personally started already a few threads on debian-devel about the security of secure APT. The most recent one was IIRC: https://lists.debian.org/debian-devel/2012/03/msg00549.html but I've had one before, I think. I think such bug shows that we can't just move on as we did till now... From the APT perspective: - Do we have unit checks now in APT, which basically test all commands with unsigned repos, repos with invalid signature, packages where the sums don't match the valid repo signatures, etc.? We really should have this,.. and also check for things like expiry dates. - I also think that there should be one place of code that handles all downloads of packages, so that we have some rock solid functions, which do all the checks and verifications. - I think per default APT should refuse to work with unsigned repos/packages. One should really need some configuration switch or option that allows this. I don't think it's a big issue, since all the major repos are signed and even the "end-user" tools to make own repos (like debarchiver) support signing. People should simply be taught to not use unsigned repos... - That being said,... APT should always delete all cached files (repo lists, signature files, Package and Source lists as well as downloaded packages) as soon as a single verification error occurred at some place. And since 3rd party programs or users may manually take stuff from places like /var/lib/apt/lists or /var/cache/apt/archives... these directories should contain a subdir like "unsecured/" where APT downloads stuff to and only moves it out from there once all checks have been passed. - In case any even just remotely possible security issue occurs... apt should exit with a non-zero status and not just a warning wich shell scripts from users usually won't check for. What about 3rd party programs and Debian in general: There are still probably many programs which download stuff without any verification,... or just warn which may be easily overseen: - [c]debootstrap I think they both default now to verify signatures (which is a good thing)... but IIRC, debootstrap also defaults to not verify anything... if the keyrings aren't installed - admittedly this is unlikely... but possible... I've already had a discussion at the respective bug with upstream, but nothing happened... I think such choices make it easily happen for security critical situations to occur... completely unnecessary. - not really secure APT related: apt-listbugs Not sure whether it uses https for getting bug infos... but since Debian nowadays uses certs from GANDI, which we generally cannot trust,... this is probably moot anyway. Securely showing bugs, may be important for users, since they want to now about bugs like "big security hole in package XYZ - don't install" - apt-listchanges Guess that uses local files an is therefore secure. - apt-file Last time I checked, the bug about not verifying the sums of the Contents-* files was still open - what about our build daemons and building tools like piuparts, pbuilder, pbuilder-uml, debian-builder or qemubuilder Do they use secure APT in ALL places? Is this constantly checked by some unit tests? Or are they easily tricked into using possibly insecure files, by depending on exit statuses which are perhaps not != 0 in case of security problems ... or by using files which were downloaded but not removed when it was found out that they're insecure. I think a package like e.g. pbuilder might easily operate insecurely... it depends on [c]debootstrap for building... if debootstrap is used, but debian-archive-keyring is not installed, then (IIRC) no signature checking is done... in that case forged stuff may be downloaded, chrooted into... and *bam* - already lost the game... and you don't even need a hole like APT not checking files it gets with apt-get source. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature