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

Re: YUM security issues...

Yes, you clearly described one of the attacks we see with MirrorManager.

A few comments:

> 1) Have MirrorManager use https and return some repo verification data.

Is the verification data a signed repomd.xml?   Can you expand on this a little?

By the way, before I forget it would be a good idea to avoid using a
detached signature for repomd.xml.   If you have the signature and
data in separate files, you can have false positives for incorrect
signatures (for example when the files are updated).

> 2) Sign the repo data, and if it's older than X, don't use it (I don't like
>   this solution, but it's probably the easiest, just push out a new
>   signed repo file once a day, even if nothing changes.)

You also want to make sure clients don't accept older versions of the
metadata than what they've seen.   In other words, if they'll accept
metadata up to 1 week old, and they've downloaded metadata from
yesterday, they shouldn't accept metadata that was signed 5 days ago.

> 3) Always get repo data from fedoraproject.org (probably not practical due
>    to resource issues)

I think this is similar to what openSUSE / SUSE Linux Enterprise do
(they actually serve signed metadata from their Download Redirector),
so it may be practical for you to do in practice.   However, you need
to worry about man-in-the-middle attackers...

> 4) use DNS, have the client query
>   <repodata sha1sum>.repo.fedoraproject.org
>   if the lookup fails, the repo is invalid.  (this is really cheap from a
>   resource standpoint, but hard to do technically)

Same comment about man-in-the-middle attacks.   DNS-cache poisoning
trivially circumvents this protection...


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