Re: thoughts on blocking and downgrade attacks agains secure APT
On Mon, Mar 19, 2012 at 02:33, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> - Is APT (apt-get) using it in all places, i.e. not just apt-get
> upgrade/install/update but also source?
Indexes are only downloaded with 'apt-get update' - front-ends usually
use either this directly or the code in the libapt library. I have no
knowledge about a front-end doing this on their own (which, frankly
speaking would be insane) - how the warnings/errors are presented
(if at all) is the choice of the front-end of course and this
varies widely.
All other commands use these indexes - as they are securely
placed on the disk - to download whatever they need if they need.
Again, i don't know what all front-ends do, but the code is in the library
to download deb files as well as sources or whatever you might need -
provided that the indexes include a checksum for these files of course.
Especially, as we had a question about that the other day:
apt-get source downloads checked sources, so if have a normal
paranoid level you can ignore the message from 'dpkg-source' about
being unable to verify the signature of the dsc file. More paranoid
people can just install the keyring this dpkg command needs though.
(Yes, the dsc file contains checksums, but used are the checksums
from the Sources file (which has a copy of the dsc file checksums)
as this one is checksummed in the Release file.)
> - When verification fails for some reason, are the respective files
> in /var/log/apt removed and are any previous files removed before an
> update?
Nothing is removed from /var/log/apt. If you mean /var/lib/apt: maybe ;)
It depends on which specific file we talk about and which error is
encountered, but usually if the "new" files fail a check the old ones are
restored and a message about that is print.
Either way, i wouldn't depend on that as this internal handling can
change anytime much like everything else in /var/lib …
If you mean /var/cache/apt/archives - downloaded files are checked by
the checksum in the indexes, already downloaded files not -
only filesize is checked for these, given that only root can modify these
local files.
> - 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?
Beside that apt-get has such a command now, too, i haven't checked
what it does, but i would seriously doubt that it does an insecure
download. It's just too easy to do it securely…
> - Do the clients further down handle all security related errors by APT
> correctly?
Does programs have bugs?
If you ask in such a unspecific way, i would say no to your question.
I would even say no if your question is if APT handles everything correctly.
We are properly trying hard, but claiming that we are in fact perfect
would be a bold statement - and easy to refute.
> - 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).
apt-get has non-zero exit for all situation warnings or errors are raised.
What other tools do, who knows…
But keep in mind that missing Release{,.gpg} files are not even a warning
as we happily work with unsigned repositories, too.
Other places exist in which what should be a warning is only a notice
as it would break existing tools otherwise (try "apt-cache show awk").
> I) Blocking attacks:
> He could prevent some files or all files from one or several given
> repositories from being downloaded at all (or correctly).
Yes an attacker can, as hinted in the last paragraph, prevent
the download of Release files. 'apt-get update' will be happy but
all apt-get operations downloading e.g. deb files from this repository
will complain about the unsigned source and ask if you are sure
(the question defaults to no).
> If they're incorrectly downgraded, I hope/assume, that APT already
> removes them immediately.
I don't know what you want to tell us with "downgrade" in this context,
so i can't answer that…
> 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.
apt/squeeze supports the Valid-Until header.
If you are more paranoid Acquire::Max-ValidTime is your friend.
> 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.
The source is still a trusted one and provided that you have a correct
setup there is no "wrong" version chosen but a "less preferable"
version. Yet, less is still more than nothing and there is only a
certain limit in how much you can protect yourself against
replay-attacks in this context in general.
> 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)?
Mhh, yeah, in this case you shouldn't use scripts and/or read more.
Really, if you care for security, but are unwilling to read a few lines of
output we can't help you. It's like saying you are frightened that you
might drive over a red stop light but are unwilling to look if the light
is red before driving over the street…
A script can check for exit codes or work with grep or alike -
or you are going for python-apt to directly control what you do.
Either way, someone has to read that - and another has to trust that
the reader did a good job.
> 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.
That is the case currently and many people consider this a bug
arguing that this a deny of service attack. I personally tend to agree
to this, but have many more problems to work on than, so if someone
really wants that changed it's properly faster to provide a patch…
(or buy me a beer - my todo list tends to be open to bribery… ;) )
> 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.
I disagree. Old data is still valid data and the information is correct for
what APT knows and correct in terms of what apt-get will work on.
How should APT know that the future already arrived on everyones computer -
expect yours, of course? In the end, the command is called *cache* and
not *realtime*… In a way you happen to work always on old data.
Sometimes it is just not-yet replaced by newer data…
> 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.
Please fill bugs if you have specific problems - this mail is quiet long,
yet very unspecific and many aspects either wrong or unreproducible.
That's frustrating for a developer and also frustrating for you as i can't
answer in a satisfying way.
Also, if you really want to talk to experts in regards to specific packages,
it's a good idea to contact the specific maintainer(s). Just because APT
is a debian native tool (unfortunately) doesn't mean that all debian
developers are experts on it. It just means that (hopefully) some
debian contributors (yes, not necessarily developers) are upstream
for this package. In your case deity@lists.debian.org has the experts
(but i should warn you:
1. this is not a big army
2. you might end up talking to me again
3. not every front-end has a representative on that list
4. it's not high-traffic, but sometimes too much to answer all
(3) might not be true through as we have way more front-ends
than front-end developers…)
Hope this helps a bit.
Best regards
David Kalnischkies
Reply to: