Re: YUM security issues...

Toshio Kuratomi <a.badger@xxxxxxxxx> · Fri, 25 Jul 2008 18:41:27 -0700

Josh Bressers wrote:
On 25 July 2008, Matt Domsch wrote:
On Fri, Jul 25, 2008 at 01:52:26PM -0400, Josh Bressers wrote:
That's a lot of IPs though.  Can I request multiple /16s, or only one?
As many as you like.  And recall, such changes are made using your FAS
credentials.

Are these ever checked?  Does say a mail get generated every time someone
adds one of these?  My fear would be that someone could blanket quite a
large IP space without anyone noticing.  Granted that would no doubt
generate a huge volume of traffic, but if they're serving up a frozen repo,
they probably won't be pushing all that much data.

How many mirrors are doing this?
374 total Hosts
185 have at least 1 netblock entry
94 of these are "private" - don't serve the public

wow, that's quite a few.  I wasn't expecting numbers this high honestly.

Does the mirror have to be part of the /16 to request it?
no.  Take for example Dell's mirrors.  Netblock 143.166/16 is Dell US,
but the mirror IPs are located inside the 10/8 private space.

OK, so here is the problem the way I see it, signing the repository won't
fix it.  I'll try to explain this clearly, Justin can yell at me if I've
gotten any of this wrong.

So let's say Mallory (the bad guy) decides that he wants to host a
malicious mirror and wait for a nasty security flaw.  He sets up his mirror
and even claims some IP subnets to serve.  Bob and Alice are happily
installing valid updates from him for some period of time.  Since Mallory
has claimed to serve a specific subnet, he has a rather impressive view of
what Bob and Alice have installed.

Now let's say there is a horrible security bug found in a mail server.
Mallory knows for a fact that Bob and Alice both have it installed as he's
been their mirror for a while.  Mallory stops updating his mirror, so none
of the users being served will get the mail server updates.  Mallory also
knows the IP address of the vulnerable clients and can easily break into
their systems.

So from what I understand MirrorManager will check on the mirrors to ensure
they're not out of date.  Mallory knows this and makes sure that when
MirrorManager connects to his mirror, it lies and serves up current
metadata.

So here is the problem.  The repodata was valid.  The packages are signed.
Even if we sign the repodata, this attack works.  Being able to acquire an
IP block simply makes this attack easier to do.  It's still very possible
that a bad mirror will wait for users to connect, serve up old content then
use this knowledge to break into their system.

What this problem boils down to, is we need a way for clients to ask
MirrorManager what the current valid repo data is.  Ideally we want the
results to be signed in some manner so it can't be spoofed.

Some thoughts I've had are:

1) Have MirrorManager use https and return some repo verification data.
We'd need to push repo verification data for both the latest and 
previous repo information.  MirrorManager would have to be updated with 
new data as part of the updates/rawhide push so that it's always up to 
date with the mirror.  We'll have to revise mirrormanager's caching 
model so that it always has access to the latest repository verification 
information.

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.)
This is going to have to have some policy attached to it.  Do we 
continue to sign the repo data for EOL releases because people use them 
even though we tell people they're EOL?

3) Always get repo data from fedoraproject.org (probably not practical due
    to resource issues)
This is the easiest to implement.  It means the small repomd.xml file 
always comes from our server.  But the rest of the metadata can come 
from the individual mirrors.  However, it does mean that *very* large 
swaths of the mirrors will be unable to serve packages to users at any 
time because their metadata won't match with ours for some period after 
we have an update pushed.  Maybe we could do this with versioned 
repodata and the client can decide how far back in time or how many past 
revisions it is willing to accept.

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)

I don't know enough about implementing this one to comment.

Also, all of these solutions need client-side support.  That being the 
case, it should be generic enough that other repomd consuming clients 
and distributions will be willing to use it.  Otherwise we'll be 
securing our updates and mirror infrastructure with the default package 
manager but doing nothing for the ecosystem as a whole.

-Toshio

Attachment:
signature.asc

Description: OpenPGP digital signature
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list