FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-19-2012, 12:33 AM
Christoph Anton Mitterer
 
Default thoughts on blocking and downgrade attacks agains secure APT

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.
 
Old 03-19-2012, 12:58 AM
Christoph Anton Mitterer
 
Default thoughts on blocking and downgrade attacks agains secure APT

(sorry for the double posting,.. my MUA crashed in between)


One addition immediately which is however not directly related to the
discussion.

I stumbled across those issues when I spent some thoughts on the
check_apt test from Nagios.

I wanted a fully secure way to be notified when updates are in place
(but not having them automatically installed).


As you can imagine now, the issues described above apply to check_apt,
too, and an attacker could trick me into not recognising available
updates.


I've opened a Nagios bug #300
(http://tracker.nagios.org/view.php?id=300) asking for improvements.
I describe the general issue there, but I have so far no details on how
it should securely "access" APT to gather the necessary information.



Which Debian secure APT experts could I ask for help with this?


Cheers,
Chris.
 
Old 03-19-2012, 07:02 PM
Chris Knadle
 
Default thoughts on blocking and downgrade attacks agains secure APT

On Sunday, March 18, 2012 21:33:05, Christoph Anton Mitterer wrote:
> 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 using 'apt-get source <pkg>' the .dsc file downloaded contains both
checksums and a gpg signature, so I believe the answer is yes. I don't recall
if this is explicitly explained in the Debian New Maintainer's Guide, Policy
Manual, or the Reference Manual -- but those are three documents to look
through to get more specific answers for these issues.

However one of the exceptions has to do with packages that are actually
"application downloaders" which has recently been discussed on this list. How
the downloaded application files are checked in these types of packages
depends on the individual package, and could possibly not be done at all.

> - When verification fails for some reason, are the respective files
> in /var/log/apt removed and are any previous files removed before an
> update?

When a package is updated usually the files related to that package are
removed before the new version is installed. This does not guarantee that all
files related to the pacakge are removed though, because occasionally a
package creates a new file during the installation that is used by the
package, but is not "part of the package", so won't be removed. These files
are generally minor configs and not executable.

> - 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?

AFAIK Aptitude will throw a warning if you're about to try to install/download
a package that has an unknown gpg signature, and you have to override the
warning to continue.

> - Do the clients further down handle all security related errors by APT
> correctly?

I don't understand what this is asking.

> - 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).

I think it's best to test it to find out.

> 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):

If you look at 'man 5 apt_preferences' you'll see that apt gives default
preference to installing the most up-to-date version. Downgrading a package
requires root access, and at the point an attacker has local root access
security is already moot.

-- Chris

--
Chris Knadle
Chris.Knadle@coredump.us


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201203191602.56404.Chris.Knadle@coredump.us">http://lists.debian.org/201203191602.56404.Chris.Knadle@coredump.us
 
Old 03-20-2012, 11:13 AM
David Kalnischkies
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAZ6_fCyhKQyn9MQ3LznjfrTcK9Bzr_5QXp_4Si2fHbVHOuY= A@mail.gmail.com">http://lists.debian.org/CAAZ6_fCyhKQyn9MQ3LznjfrTcK9Bzr_5QXp_4Si2fHbVHOuY= A@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 11:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org