YUM security issues...

[seth vidal]

On Fri, 2008-07-25 at 19:04 -0700, Justin Cappos wrote:
> 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).

And if that happens then it regets to another mirror and attempts to
find a valid cert. Detached sigs is how it will be b/c otherwise we're
breaking backward compat with older clients. And that's just chockful of
pain.


> > 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.

And do what if they can't? think about it - at some point every repo
will be 'too old' and then what? The client cannot use it at all? If
that's the case then we're intentionally putting a sundown into our
code, what a nightmare that is.

The best we can do is warn and alert the user that the metadata is old.
Stopping working is just preposterous - it's just a different kind of
DoS if we do that. If the user cannot read and take warnings then there
is really nothing that can be done for them.

-sv