[Yum-devel] Is YUM really a secure package manager ?

[Seth Vidal]

On Tue, 22 Sep 2009, Akshay Wattal wrote:

>
> Hi,
>
> i do agree on using signed repository metadata by YUM, but does it 
> prevent the "freeze attack" in which the version of the packages can be 
> compromised....for example showing version 1.1 again and again even if 
> newer version is present

This is really a function of two things:
1. the type of repo you use

     - use the metalinks repo then you have an ssl cert and a bunch of 
other data to go by. So compromising the repository server is considerably 
harder. Making it show the same data

2. how you setup the local machine
     - setup the local system to complain if a repo never updates. We can't 
easily implement this by default b/c of the problem of repos which are one 
shots and then, intentionally, never update. For example the GA fedora 
releases. They get pushed once and then all new pkgs are in the
updates/updates-testing repos. Does it make sense to make accesses to the 
fedora release repo stop working just b/c the repodata has not been 
updated? I'd be fine with including some sort of option to do this - but 
it could be done, now, as a plugin.

> Also what about Endless Data Attack....in which the mallicious party 
> sender keeps sending data endlessly, in this case how can YUM terminate 
> the connection.

Out of curiosity - how does firefox deal with this? Not all sites send a 
content-length header. Especially ftp-based sites.

I can see some fixes for it that wouldn't be too hard - I'm just not sure 
it is a serious issue.

It's a pretty convoluted way to DoS a system:

1. compromise a mirror of a url
2. modify the server to send an endless stream of data
3. wait for the client to fallover from memory or disk exhaustion.

Having said that: 
The new version of urlgrabber is pycurl based - I'll put a check into 
urlgrabber to bail out if the content-length is <  current size. And we 
can set a max on it to some arbitrary number. so if the site doesn't 
publish a content-length we can still bail.


If you are very concerned with security of yum I would recommend:
1. sign your repos
2. use https repos with valid certs
3. do not let your clients access repos beyond your local network

-sv