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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature