YUM security issues...
seth vidal
skvidal at fedoraproject.org
Mon Jul 28 19:30:57 UTC 2008
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
More information about the Fedora-infrastructure-list
mailing list