Re: A Look In the Mirror: Attacks on Package Managers
On Sun, Jun 6, 2010 at 1:37 AM, Michael Gilbert
<michael.s.gilbert@gmail.com> wrote:
> All of the issues raised in this paper can be mitigated by a "proactive"
> user. Malicious mirror activity can be detected by paying attention to
> debsecan and the security tracker [0]. debsecan displays all known
> vulnerable packages on a particular system, and the security tracker
> displays all known vulnerable packages. Differences between the two for
> a period longer than about a week would be a sign that the mirror is
> intentionally holding back vulnerable packages.
>
> Of course the major flaw with this statement is that there aren't a
> whole these "proactive" users. However, if there are enough, some will
> spot the activity, and raise concern, which will ultimately protect
> others when the evil mirror is shut down.
Agreed.
I'd like to point out that since we sign root metadata, it's
impossible to keep some packages outdated (say, daemons facing the
internet) while others are up-to-date. What this means is that a
replay or freeze attack is very unlikely to go unnoticed. Lots of
packages being downgraded, no updates for too long, things like that
stand out. If an admin doesn't notice that, I find it unlikely that he
or she will notice a stale mirror warning either.
Moreover, as people have said already, stable is safe because security
updates come directly from security.debian.org, not from mirrors. The
remaining issues I see are:
1. Man-in-the-middle attacks between clients and security update servers
2. Denial-of-service attacks to the security updates infrastructure
3. No trusted servers for security updates for testing and unstable
Using HTTPS for the security update infrastructure could solve #1, but
not much can be done about #2 (though such an attack would be
Hollywood-esque in scale).
Now if we had a timestamp in the root metadata updated on a daily
basis, that would solve #1 and #3 (or anything else related to replay
attacks), and it doesn't sound too hard to implement (of course, talk
is cheap). #2 is not quite under our control.
Another idea would be actively comparing mirrors to make sure evil or
dead mirrors are removed from our list of mirrors (if that isn't the
case already). Not much can be done if the end user isn't being
notified, though. Coupled to that, maybe some sort of PKI could make
it possible to revoke the hability of the mirror to advertise itself
as a trusted, up-to-date mirror.
The bottomline seems to be that stable is safe enough, whereas if you
use something else you're on your own as usual, but I believe we can
improve this situation.
I'm neither a security guy nor a Debian infrastructure guy, so please
take my words with a grain of salt.
Reply to: