Surely package signing already solves this?

Posted Jul 15, 2008 1:53 UTC (Tue) by PaulWay (guest, #45600)
Parent article: Study: Attacks on package managers

I may be missing something, but surely the package signatures that are already in place make
this "black mirror" an unlikely attack vector?  AFAICS they're not creating a new repository
with their own package signing key, so you're still using your core package signatures to
verify that the RPM or DEB that you've downloaded hasn't been tampered with.  Unless they can
break that security, they can't introduce new vulnerabilities or back doors.

So the only real possibility is for them to keep only the packages that have known
vulnerabilities, which would mean that unless your victims had listed your mirror first in an
in-order (i.e. not round-robin or random) list, you would only have a small window of
opportunity to trace the victim that downloaded the vulnerable package and exploit it before
they did their next update from someone else and got an updated package with the vulnerability
fixed.  Otherwise you have a much smaller chance that they pick your mirror when you're
holding the newer-but-insecure package.  And if you're holding out-of-date packages or
fiddling with package names then the repository maintainers will probably fairly quickly spot
this from their own surveys and block you anyway.

This sounds similar to someone saying "wow, I'm so leet, I found this uber warez site and
downloaded Linux for free!"

Surely package signing already solves this?

Posted Jul 15, 2008 3:52 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] (2 responses)

The attack is for the mirror to serve up old (but digitally signed) versions of the packages that have known vulnerabilities. But the problem is that apt and yum won't downgrade packages, so this isn't much of an attack.

Surely package signing already solves this?

Posted Jul 15, 2008 22:11 UTC (Tue) by njs (subscriber, #40338) [Link] (1 responses)

One could sign packages in such a way that a replay attack was impossible... assuming that the
client has an accurate clock.

Have a root-level signature re-issued each day over the entire repository, that also includes
the date that it is generated. When talking to a mirror, you can check this root file, and if
it's more than a day or two old, that's a bad mirror and should be ignored. (This also
catches mirrors that are merely stale, which can be a problem sometimes for entirely
non-malicious reasons...) Because the date is signed, the mirror can't pretend to be
up-to-date.

Of course, the signature has to also cover the packages in the repository or it's no use -- a
malicious mirror could serve up a fresh root cert and stale packages, and verifying a
signature made in the naive way over the entire repository would be prohibitively expensive.
(Heck, *generating* such a signature would be prohibitively expensive...) But one could create
a tree of signatures to mitigate this -- the root signs a list of package/version/hash, and
then you just have to download the root, the list of package versions (which you usually
download anyway), and the actual packages you want...

If clients don't have accurate clocks, you could instead put the current root signature on a
single centralized server run by a trusted party (i.e. the distribution itself), and have
everyone fetch it directly; this would be reasonable scalable, since the central box would
only have to serve one few-hundred-byte file instead of being a full mirror.

Not that I expect anyone to do this, but it's fun to think about.

Surely package signing already solves this?

Posted Jul 16, 2008 17:04 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

I would like the CDs to contain signed repositories as well.

A valid mirror and an up-to-date mirror are not necessarily the same thing.