Package Managers As Achilles Heel 263
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.
verify against other sites (Score:5, Interesting)
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 actual vulnerability (Score:5, Interesting)
> 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.
debtorrent sounds neat (Score:3, Interesting)
from the cert overview:
Another potential solution to this problem is P2P technology. If widely used, programs like DebTorrent may allow official repositories to distribute metadata and tracker information while decreasing bandwidth costs.
I wonder why Ubuntu doesn't make this a standard option. Is port forwarding too complicated? From what I understand, if the package is not available via bittorrent, DebTorrent degrades to using http.
Re:Package are already *signed* (Score:5, Interesting)
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.
Re:Package are already *signed* (Score:4, Interesting)
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.
Re:The actual vulnerability (Score:2, Interesting)
To give one example of why it can be bad for a package manager to accept older metadata when it has previously seen more recent (valid/signed) metadata: If you are installing a new package (rather than updating a package) and the old package you are served doesn't conflict with your currently installed packages, you will be installing a package that may have known security vulnerabilities. Additionally, the attacker who gave you that package may know your IP address now.
In this case it does not matter that the packages are signed. And if the metadata isn't signed, the above still applies but is easier to exploit.
Well, sign the catalog then. (Score:1, Interesting)
Hmm. How to defeat that. Easy enough.
Firstly, the catalog would have to be signed. (The list of the current versions of the packages, I guess it's the metadata rather than the data.) And it would have to have a datestamp in it. And the catalogue would have a copy (or the copy of) the signature that would otherwise be attached to the packages themselves.
Then it's easy for a client machine to verify the catalog is correct (is correctly signed by a trusted key). Validate the datestamp in it and alert if the catalog is old (say, older than three months ago). When you download a package, it takes the signature from the trusted catalog and uses that signature to verify the package, proving the package file is a currently supported version.
(If the package download doesn't match the signature then it will fail the signature check like any other modification. Technically, checking this is a fullly signed singature isn't required, merely that it matches a cryptographically secure hash in the catalog but I imagine it's safer and easer to just verify the signature on the package in its own right. Packages may carry the signature themselves which would allow stand alone installations of the package - but of course, no guarentee that it is the latest version.)
Yes, this means monthly updates to the catalog, but the only parts changing (aside from actual updates) are the catalog datestamp and catalog signature, which I imagine would be reasonably small if something like rsync copied the data.
And, yes, this does mean a three month window for this attack. One way around that is for the 'current datestamp' to be available on a trusted central site (signed and/or SSL protected) and the package manager refuse to load a catalog until it has the catalog version that matches that current datestamp. This would probably only be a couple of hundred bytes at most. Maybe a weekly check would be sufficient.
Re:Well, sign the catalog then. (Score:5, Interesting)
I just verified with my distribution, and the package metadata is not used when calculating the signature, so this is a valid vulnerability.
Re:Compile from source yourself! (Score:1, Interesting)
Been there, done that (Score:3, Interesting)
You joke, but I've actually built gcc with a C interpreter, and used that to build gcc binaries. We did it primarily as a stress-test of the interpreter, but it was nice see that the resulting gcc binaries were the same as those built with a compiled gcc.
Re:Not a real issue with Debian today (Score:3, Interesting)
If you use the Debian Security Analyzer [www.enyo.de], you cannot simply supply vulnerable versions of packages as they will still be listed by debsecan.