Hi. I recently played with Nagios' check_apt script (more on that later) and this brought my attention to the following issues. As everyone knows, our packages/archives are in principle fully secured ("secure APT")... via signed Release files and hashsums on the other files. I personally have still several open questions, one whether this is really securely used by all clients, e.g.: - Is APT (apt-get) using it in all places, i.e. not just apt-get upgrade/install/update but also source? - When verification fails for some reason, are the respective files in /var/log/apt removed and are any previous files removed before an update? - Do the clients further down (especially aptitude, but also all the others) use it in all places? E.g. I though "aptitude download" was an aptitude specific thing... does it verify the packages downloaded? - Do the clients further down handle all security related errors by APT correctly? - Can I use all these commands (e.g. apt-get update) safely in scripting, e.g. will $? != 0, if just a single "small" problem arises in apt-get update (like a completely missing repo). Well, this may all work and it's just me who is uncertain, ... but it seems to me the following is really still open: Generally an attacker could use blocking and downgrade attacks (two distinct things): I) Blocking attacks: He could prevent some files or all files from one or several given repositories from being downloaded at all (or correctly). If they're incorrectly downgraded, I hope/assume, that APT already removes them immediately. But even then (at least) two attack vector may be left (which is basically the same as when blocking whole repositories): 1) The may not recognise that updates (i.e. security updates) are already available. This is similar to the "downgrade attack vector" I'll discuss below, so see there for more. 2) Given that Debian has the wonderful and powerful APT preferences system (with priorities to packages, etc.) it might be possible to trick a system into choosing the "wrong" packages, as some repos are missing. Especially attack vector (2) may sound quite obscure, but sometimes the complex and very unlikely ways are the best (no one expects them). I'm not sure whether the above attacks are "still" possible... the question is basically, do all clients (APT, aptitude, etc.) handle missing repositories as an error? And I really mean error,... IIRC APT and aptitude both generate warnings if a repos or some files are missing, but who's reading this (especially when something is scripted)? Rather they should stop service and continue only when command line options are specified or some interactive input has been made, that this and that specific missing repository should be ignored. II) Downgrade attacks: Similar to the attack above (I/1), an attacker might present the client (APT, aptitude, etc.) old Release/Packages/etc. files. Of course he cannot forge them (as long as he hasn't the OpenPGP key) but by presenting an old set, he can already hide the fact that security updates are available by either users, or some automatic scripting. Now as far as I can see, the necessary information to avoid this would be already in the Release files: Date: Sun, 18 Mar 2012 20:19:08 UTC Valid-Until: Sun, 25 Mar 2012 20:19:08 UTC (btw: The range seems quite long to me.) But it seems to me that this is not yet used by the clients, is it? Generally I'd say, that (from a security point of view) really ALL clients (APT and all ifs tools, aptitude, etc.) should stop working if a single repository is out of date. There may be little exceptions: - of course the update command may succeed - command line options and that like may allow users to ignore outdated repos. This sounds of course quite harsh, but IMHO it's required if one want's to be really secure. Even for tools that just list some status (e.g. apt-cache) old data may be a security problem, as we can never know by which way the output is processed by users. In principle I'd be willing to open bugs for the above but given that the impact is quite big and quite a lot is affected and I may not yet even see the whole picture,... I thought it would be better to first have a discussion with the experts on d-d. Thanks for you input, Chris.
Description: S/MIME cryptographic signature