Slashdot Mirror
Package Managers As Achilles Heel
An anonymous reader writes "Researchers from the University of Arizona have released a study that takes a look at the security of ten popular package managers. They were able to show all ten were vulnerable to attacks from a mirror or man-in-the-middle that allow an attacker to (along with other things) crash the system or obtain root access. Furthermore, the researchers created a fictitious administrator and company name and were able to lease a server and get it listed as an official mirror for all the distributions they tried (Ubuntu, Debian, Fedora, CentOS, and OpenSUSE). This raised the question: What keeps you up at night, the thought of attacks on your package manager or previously discussed and patched vulnerability in DNS?" justin samuel (one of the Arizona researchers) also points out a synopsis on CERT's blog.
I think a lot of these risks could be reduced if people downloaded from one site and verified against one or more other sites. Furthermore, if the checksums were verified over SSL, some attacks would be harder.
Right now, verifying packages against a site other than the one they were downloaded from seems cumbersome with apt--or does anybody know of a simple command line to do so?
> The article actually discusses attacks that can be made by a malicious mirror...
Yes a mirror can keep you from getting a security update. But if you don't contact that mirror every day you will eventually get a good mirror and update, and since none of the package managers will downgrade automatically this is a mostly theoretical exploit.
Yes if a really BIG bug hits somebody could keep some subset of machines from updating, and since they would also KNOW the ip of each vulnerable host it could be very bad. That is the part that worries me, hell, they could even deliver the update from their perfectly up to date repo of signed packages, signed metadata AND perfectly in sync with the distro prime mirror.... and root your ass while the update is in flight. This gets to the real security vuln involved, telling an untrusted entity exactly which version (sorta) of a package you are running.
Democrat delenda est
The packages are still signed with an a valid key. They are just older packages rather than the latest ones.
I have to give more thought to think if this will work, but I doubt that this has not occured to anyone else. I certainly thought of it before. Most likely the package managers have a way to keep this from happening already.
Their entire Proof of Concept seems to be:
I wouldn't panick until I see a CERT advisory, or as someone else pointed out, at least one real world incedent.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Just to be very clear about this one point because it is sensitive: the public mirrors we setup and had listed as official repositories were kept up-to-date and we only served current metadata and packages. We served nothing that was out-of-date (beyond normal mirror update lagtime between rsyncs with the upstream mirrors) and we served nothing that had been modified.
All tests we performed related to what a malicious mirror could do (e.g. serving out-of-date metadata, serving modified metadata in the case of package managers that don't sign metadata, etc.) were performed using separate mirrors and clients of our own. Nothing we did with our mirrors put users at risk.
Actually, it is much easier than that. Simply include the metadata for each package in the signature calculation. Every package already has an increasing number scheme. Once this is done, the filenames cannot be changed, and the package manager simply must not allow numbers to go down instead of up.
I just verified with my distribution, and the package metadata is not used when calculating the signature, so this is a valid vulnerability.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun