[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A Look In the Mirror: Attacks on Package Managers



On Sun, Jun 6, 2010 at 5:31 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Fernando Lemos:
>
>> 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,
>
> Not really, because the mirrors are already middlemen, so encrypting
> the transport to them doesn't change much.

Sorry, I think I wasn't clear enough. I mean using HTTPS for
security.debian.org, i.e., the security update servers. Regular
updates would still come from whatever mirror the user chooses, HTTPS
wouldn't help there.

>> Now if we had a timestamp in the root metadata updated on a daily
>> basis, that would solve #1 and #3
>
> Actually, it wouldn't because we do not provide a secure time source.
> pool.ntp.org faces the same theoretical issues as our mirror network.

Indeed. But if you play with the system clock, the admin is probably
going to notice it. "make", "tar" and possibly others are going to
complain about timestamps in the future. An attacker would have to
create an evil mirror and an evil NTP server, hope that some admin
uses both his evil mirror and his evil NTP server (not that unlikely
if the evil mirror and NTP server are geographically closer to the
target) and hope that the admin doesn't notice a lot of clues that
something is going on. It's one more problem an attacker would have to
deal with.

> You'd have to fetch the root metadata from a trusted server over
> something like HTTPS (that is, something with authentication and a
> challange-response component built in).

That's a good solution, but, as mentioned before, that would generate
a lot of false positives. Mirrors only synchronize every X hours. If
you happened to download the root metadata from the trusted server
before the mirror catched up, you'd be told the mirror is stale when
in fact it's perfectly healthy.

Perhaps the trusted server could serve the root metadata mentioning
packages available from time() - X hours before through time(), where
X is the maximum delay between a mirror and the master servers.


Reply to: