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.
Re:Compile from source yourself! (Score:5, Insightful)
How does compiling from source help? Trojans can be introduced in source code just as easily as in binaries.
Re:Compile from source yourself! (Score:3, Insightful)
Re:Compile from source yourself! (Score:1, Insightful)
It's also very easy to hunt down hundreds of dependencies, right?
Re:Compile from source yourself! (Score:4, Insightful)
I really don't understand what the big advantage is in using package managers. It's dangerous because you never know what "updates" will come down the pike.
Normal people don't want to have to keep up on what the latest version of everything is as it comes out and what security holes are in it. That's one of the main reasons people use distributions instead of hacking together their own. People want knowledgeable experts to make the decisions and let the computer do the rest.
Re:Compile from source yourself! (Score:5, Insightful)
Unfortunately it's not nearly as easy to type: ... ... x20
wget http://blahblah/dep1.tar.gz [blahblah]
wget http://foobar/dep2.tar.gz [foobar] (404 Sigh)
wget http://woobar/dep2.tar.gz [woobar]
wget ftp://wowowow/dep2.1.tar.gz [wowowow]
Followed by:
tar -zxvf files.tgz x 20
THEN followed by: ./configure && make && make install x20 IN THE RIGHT ORDER
times
Plus however long it takes you to debug the eventual compile problems because one of those obscure libraries that only one program uses was installed earlier with the wrong version.
All said and done, I'd rather take my chances with package managers, thanks.
Re:Compile from source yourself! (Score:5, Insightful)
If you are downloading from a mirror, someone could apply similar methods to insert malicious code in your version of the source. And checking all of the source code is no trivial matter, especially if you are looking for an intentionally obscure bit of code.
Also, you have to trust your compiler [bell-labs.com], which you *had* to get from someone else. Your compiler may be inserting malicious code.
Re:verify against other sites (Score:5, Insightful)
This doesn't really make it more secure.
That's the kind of simplistic black-and-white view of security that is responsible for so many security problems.
Of course it makes it more secure if I verify against multiple sites and over SSL: it protects against many of the attacks described in that paper, so it will be harder for an attacker to mount a successful attack.
Re:Compile from source yourself! (Score:4, Insightful)
Re:Depends on bugs in old software (Score:4, Insightful)
That's good and all until you download a bleeding edge version that is buggy as hell and want to go back to the old version.
Re:verify against other sites (Score:3, Insightful)
Anything is better then nothing, even if you don't use SSL its still better. Rather the settup a fake package server ( easy ) and dupe you into using it ( probably easy ), the attacker now must compromise your DNS ( harder ) or dupe you into useing two of his fake package servers ( harder ).
Windows Update not vulnerable? (Score:3, Insightful)
TFA doesn't address Windows much. In the FAQ they say something like "since the vendor controls the repos for Windows and OSX, they are less vulnerable".
True, I can't set up a bogus mirror for Windows -- except in a corporate environment, where I believe MS has some facility to allow a local cache of patches to reduce external bandwidth usage.
But the authors keep talking about man-in-the-middle attacks on FOSS repos. Couldn't someone just as easily do that for Windows? And then use it to only offer outdated (known-vulnerable) versions of patches?
Re:Vendors sign with keys. (Score:3, Insightful)
A server can't make your machine do jack shit. Your machine is the one that pulls an old version and downgrades to it. If your package manager silently downgrades packages then that's a flaw in all cases. What if a mirror just happens to be out of date?
Re:So, Linux is not more secure? (Score:5, Insightful)
The short answer : yes
The longer answer : every OS is vulnerable one way or another. The difference lies mostly in the response and the response time by the vendors.
Linux : take the debian ssh disaster a few month ago as example. I read about it at Google News, head over here to check how the linux bashing was coming along, and while I was reading, the "update available" icon appeared. A few minutes later and the vulnerability was no more. .. people who actually CAN fix this kind of problems, not your average /. reader)
Admitedly, it took a *VERY* long time to find out about the problem in the first place, but the response time from then on was very short, and the update contained concise information about the whole mess.
Today's vulnerability will probably take a bit longer to be fixed, as it requires some primordial changes in the way packet manager work to be fixed. But I'm rather sure people are already looking for a solution (you know
Apple Mac : when Apple admits that there is a vulnerability in their products, they take their dear sweet time to fix it. As a matter of fact, Apple just released a security fix for Apple TV, covering vulnerabilities dating back to, at least, January 2008 (at which time it was fixed for OSX, but NOT for Apple TV). I can't comment on how detailed the security fixes are, as I don't own apple products
Microsoft : the Zero Day initiative still lists 12 issues concerning Apple product, classified as "high severity", but the oldest item is a Microsoft vulnerability dating from September 2006 (more or less quoted verbatim from the iWire article I'll link to a bit later). Microsoft updates are particularly obscure in their descriptions, and, if I remember correctly, they are sometimes even applied without asking the user first, and have a bad habbit of breaking other stuff.
So, is Linux 100% secure? No, and it will never be. But at least the devs react in a timely manner, and they don't just install something without telling you what it is or that they are patching at all. Therefore it is better secured than Apple and Microsoft products whose vulnerabilities are often left open, for the sake of obscurity I suppose.
"Superiority" is a highly subjective term, so I won't even start to thread on this subject. It is for me, but your mileage might vary
Apple TV fix article [itwire.com]
Zero Day Initiative upcoming advisories [zerodayinitiative.com]
It's a true risk. (Score:3, Insightful)
Re:Sounds real and exploitable.. (Score:5, Insightful)
> One long term solution would be to sign package metadata and serve
> it only from one central location, over https/sftp.
Even that won't help. The authors got so caught up in the complex exploiting they didn't notice the BIG implication of their work. The problem can't be fixed with tech, crypto or anything but https connects to known to be trusted mirror operators.
Follow along as I demonstrate. Spamgang wants zombies so they install a massive mirror farm for all of the major distros. They run it perfectly, fully updated with upstream as fast as their phat pipe can get it, perfectly signed metadata, packages and everything offered by http or https. Then they wait.
Sooner or later another remote root bug, in openssh for example, will hit and they are ready. Thousands of machines either automatically connect or their owners see the story here on /. and hit the update button. They download that signed, correct metadata and sure enough their machines realize they need that new openssh package and ask the mirror for it. And are 0wned a few milliseconds later.
Because in the act of requesting the package all those machines just told the spamgang that a specific IP is a) running openssh, b) it is the vulnerable version and c) that host is currently connected to the network and very likely has the vulnerable software running. So in the time it takes the updated package to transfer, unpack and install they have ample time to get in and install a rootkit. The beauty is that the victim will patch the hole and thus prevent anyone else from getting the zombie.
Wait a random time before beginning to use the new zombies to help prevent people from getting wise to what is happening and the spamgang could likely get away with it for years.
Package are already *signed* (Score:5, Insightful)
No need for anything as complicated as verifying packages accross several source :
most modern package managers use key-signing on package.
You can't setup a bogus repository and start serving malware to unaware users - those packages will fail the key check.
For that to work, the crackers would also have to find a way to inject their own keys into the ISO of the distribution, and they'll have to find a way doing it that still pass the checksum of the peer-2-peer client with which the users downloaded the ISO.
That might be possible with older p2p protocols relying on older weak hash, like eDonkey2k whose MD4 has known collisions, or even older protocols lacking checksums. (Some companies working for the media corporation back then used such possibility to pose as peer on the network and poisoning it by injecting bogus packets).
But distribution currently rely on bittorrent which use SHA-1 hash and it's (currently) much harder to find a way to inject tampered data and have the resulting file still pass the checks.
Another solution would be to trick the users into accepting a new set of keys to get onto the fake repository. For this, this repository will have to pose not as a mirror (as proposed in the TFA) but as an additional 3rd party repository hold functionalities not available in the original source (this is something that would benefit from the harsh imaginary-properties laws as most distro can't provide packages processing some media, and users have to rely on 3rd party repositories for this).
Besides, the summary is misleading. They didn't actually setup a bogus mirror that served maliciously crafted files, or otherwise injected malware (that would be impossible given the signatures).
They simply setup a mirror, that wasn't up to date on purpose, potentially exposing computer to exploit due to only older versions of software being updated.
As actual legit mirror may lag behind the release, it is nevertheless preferable to always add the original repositories to the list of source : thus get the files from the mirror if available there, or straight from the original website if not replicated everywhere.
This work around is even useful when there's no malicious intent.
Re:Compile from source yourself! (Score:3, Insightful)
Hear! Hear!
When it becomes a problem like it is for Windows, I will then take notice.
From my point of view, it's all 'nothing to see here, move along.'
I will admit that the increasing popularity of *nix will eventually will make this an issue, the time is not now. Give it a few years and marketshare increase on the desktop.
The source is always available to be checked, so I don't see a problem here unless someone like MS is trying to 'poison the well' to try to increase their marketshare. This is FUD as far as I am concerned. (I maintain backups, so WTF?!- let's see a problem with this before we jump the gun(or shark))
Re:The actual vulnerability (Score:2, Insightful)
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.
Also, the article says "the malicious mirror can provide the client a signed list of packages from the year before", but I don't see how that can cause a problem, either, if I have updated a package within that year.
If I have foo-3.1.0 installed and the malicious mirror offers me foo-2.8.0, then I won't download it, because it doesn't provide newer versions of anything.
The big key in all of this is signed packages (no pun intended), since that keeps the bad guys from modifying the package to claim to be foo-3.2.0 but really contain trojan-1.0.0. As long as the packages are signed, I can't see anything that a malicious mirror could do other than delaying you getting updates for a few days, which isn't good, but its really no different from waiting a day or two to update your production system until you have time to make sure the updates don't break anything.
Re:Answer (Score:2, Insightful)
Re:The actual vulnerability (Score:3, Insightful)
No. Your missing how it is done. The cracker mirror takes foo-2.8.0 and renames it foo-3.1.1
Since the file metadata (e.g. filename) isn't used in the signature calculation it still verifies as a valid signed package, and the system installs foo-2.8.0 because it believes it is foo-3.1.1.
AFAICT - Debian is not vulnerable by default (Score:5, Insightful)
As far as I can tell, Debian is not vulnerable in its default install mode.
a - Debian will never automatically downgrade a package.
b - Security problems (as opposed to mere changes) get published in the Debian security repository.
c - The Debian installer automatically adds the debian security mirror to the end of your sources file.
So, you can create a mirror, easily inject it into the list of official Debian mirrors, and freeze the packages offered on it. You can do all that easily. It won't help you. If you take the CERT example, of the vulnerable openssl package, the fix was pushed through the security repository, and that is added by default to all new Debian installations. The attack would fail.
Furthermore, even if your mirror offered a security mirror as well, I, personally, always keep the Debian source as well, lower in the list. This way, if the local security mirror is up to date, I take stuff from there. If it's not, I take it from the Debian server. This means that even if you deviate from the default behavior, you can still be not vulnerable.
Shachar
That's why Debian signs repositories (Score:4, Insightful)
They're saying that signing the package isn't good enough
That's why Debian doesn't sign packages; they sign repositories. (Actually, they sign a list of md5sums of all avaiable packages.) You can actually argue that signing a package is counterproductive--it means that an insecure package out in the wild will still have a valid signature.
When you sign the repository, then an attacker has to freeze their whole repository if they want to keep the insecure package available. For Debian Unstable, people will get very suspicious if more than two days go by without any updates. And for Debian Stable, well, the security repository isn't mirrored, so owning an "official" mirror won't help you there. (The security repository could be vulnerable to a MITM attack, but then so could MS's system.)
So, while the attack vector they mention for Debian seems superficially plausible, in practice, it's unlikely to be as effective as they suggest.
Slackware (Score:3, Insightful)
There seem to be a lot of distributions whose package managers rely on the keys/hashes to "secure" the packages, where the mirrors are providing those keys/hashes. Silly idea - always has been, what makes this news?
What this article is basically saying is "anyone can be a mirror" (Yes, that's the point, without that you wouldn't be able to get a release/security update for ages after its release, or you could just take one website offline and stop all package updates worldwide - both are worse for security than the alternative) and "some package managers don't properly check the authenticity of a package from a mirror". The second is a problem that's easily fixed and shouldn't be present, granted. What idiot would accept a valid signed package without first checking that the root key it's signed with isn't current, valid and not revoked? This is like your web browser navigating to random SSL websites without first checking that the certificate chain is correct and valid and ends in a trusted root.
1) Download key from "redhat.com" or wherever (DO NOT USE MIRRORS), or from the CD, on first install.
2) Everytime you are asked to fetch a list of available packages, check the authenticity of that key against "redhat.com" directly (DO NOT USE MIRRORS), check the expiry date, check for revocation information, or allow the user to override (their fault), or check public keychains.
3) If the key ever changes, ALERT THE USER before you do anything with it (don't try and get smart by signing a package with the old key that introduces the new key to the world, or automatically accepting a new key). Then the distribution should NEVER use that old key ever again, and maybe even resign all old packages with the new key.
4) Use that key to verify all packages downloaded from any mirror against the GPG signature from that package (for ultra-security, get that from a second, random mirror, or the official website).
There's a small window of opportunity for compromise on machines that install packages without checking first, or assume that because a key was once valid it always will be, or are significantly out of date and don't check the "definitive" source for a new key first but you'll never remove that completely. The way to do that is to check the root key, reliably, on a regular basis. But then if you have an old machine that still has the key from the install CD, and that key is compromised, and the machine does not have reliable (read SSL with significant trusted chain) means of contacting the main server without possibility of spoofing for a new key, then you have a problem.
I don't see why this is "news" or even vaguely important except to show up distros that aren't ALREADY doing it this way.
BTW: This is why I do package management on Slackware using a script that makes *me* get the GPG-KEY from slackware.com first if it ever changes (including checking if the IP of ftp.slackware.com has changed, the date of the file has changed, the key itself has changed etc. but if they can compromise my access to Slackware.com without hitting one of those checks, I'm stuffed anyway), why I have an RSS feed of Slackware and check the website myself regularly (just in case the key requires changing and news is posted about it), why I only use trusted mirrors, why I download the GPG signature and package from seperate mirrors and why nothing gets installed without that GPG check succeeding. To be honest, I see this just as being sensible for anything that goes into production. I'm still waiting for a rogue Windows Update, but it surprises me that some distros (or administrators) don't ALREADY do all this...
Re:Why do mirrors exist? (Score:3, Insightful)
Well, to start with, Bittorrent is P2P, and some ISPs block it. In an ideal world you might have a point, but I'm not going to think about it too much. Alas, we live in a world where network neutrality is not a given, and they may start arresting people for using BitTorrent any day now :-(
... I hope I am being alarmist with that last part, but it wouldn't surprise me if the next step after Telecom Immunity is P2P Gitmo.