YUM security issues...

[Justin Cappos]

I was wondering if any changes have been made or are planned for
MirrorManager (i.e. preventing mirrors from arbitrary grabbing parts
of the address space).   We're submitting the final version of our
paper soon (the version that will appear in print) and I'd like to
include any updates about this.

Thanks,
Justin


On Fri, Jul 25, 2008 at 6:11 PM, Josh Bressers <bressers at redhat.com> 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.
> 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.)
> 3) Always get repo data from fedoraproject.org (probably not practical due
>    to resource issues)
> 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)
> 5) ???
>
> Thanks.
>
> --
>    JB
>