Slashdot Log In
Package Managers As Achilles Heel
Posted by
timothy
on Thu Jul 10, 2008 05:53 PM
from the dip-your-computer-in-the-styx dept.
from the dip-your-computer-in-the-styx dept.
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.
Related Stories
[+]
Massive, Coordinated Patch To the DNS Released 315 comments
tkrabec alerts us to a CERT advisory announcing a massive, multi-vendor DNS patch released today. Early this year, researcher Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients. Kaminsky has been working in secret with a large group of vendors on a coordinated patch. Eighty-one vendors are listed in the CERT advisory (DOC). Here is the executive overview (PDF) to the CERT advisory — text reproduced at the link above. There's a podcast interview with Dan Kaminsky too. His site has a DNS checker tool on the top page. "The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not [immediately] reveal the vulnerability and reverse engineering isn't directly possible."
Submission: Package Managers an Achilles Heel? by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Answer (Score:5, Funny)
What keeps you up at night, the thought of attacks on your package?
Yes.
Re:Answer (Score:5, Funny)
Parent
Re:Answer (Score:5, Funny)
Parent
Re:Answer (Score:4, Funny)
Iran's missile keeps me up at night more than my Ubuntu's package manager.
That depends on whether you live next door to one launchpad or the the other [launchpad.net].
Parent
I better update now (Score:5, Funny)
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?
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.
Parent
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.
Parent
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.
Parent
Re:Well, sign the catalog then. (Score:5, Informative)
Parent
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.
Parent
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.
Parent
Re: (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 ).
Depends on bugs in old software (Score:5, Informative)
Just in case anyone thought (like me) that the vulnerabilities they're talking about might let an attacker install arbitrary software just through the package manager, this doesn't seem to be the case.
The attack might go like so:
The simple fix is to change the client so that it never regresses (e.g., never installs software older than what it already has installed).
Re:Depends on bugs in old software (Score:5, Informative)
The simple fix is to change the client so that it never regresses (e.g., never installs software older than what it already has installed).
That's a start, but then they can just keep you at the current version and when a new buffer overflow is found and an exploit created, then they hack you. Better validation of mirrors and package managers that check multiple repositories and compare the results are probably a more complete fix.
Parent
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.
Parent
"project" managers (Score:3, Funny)
The headline should be project managers as achilles heal.
Sounds real and exploitable.. (Score:5, Informative)
Until I RTFA, I was ready to dismiss this as 'failing to understand signed packages. Wrong, they understand package signatures all too well.
The basic attacks seems to be.
1. Obtain old, signed packages.
2. Become a mirror for debian|fedora|ubuntu|$distro.
3. Wait for vulnerabilities to be found in some package.
4. Do not serve the updated packages, continue to serve the vulnerable version.
5. Log IPs of machines downloading from your mirror.
6. Root them.
This works because some package manager software will download and use package metadata even if it's older than what's cached.
One long term solution would be to sign package metadata and serve it only from one central location, over https/sftp. There may be others.
Alex
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.
Parent
Re:Sounds real and exploitable.. (Score:5, Informative)
Parent
Not a real issue with Debian today (Score:3, Informative)
they basically say so themselves
Use signed repository metadata. If your package manager or distribution does not yet support signed metadata but only signed packages, at least require signed packages until signed metadata is supported.
Debian does that. The Release file defines what Package database files are available, and their md5sum's. It is signed.
the Package files include md5sum for the packages (can't modify the Package file otherwise signed md5sum in Release file will fail, can't modify the actual package as wont match md5sum in package file).
I would argue, that manually using the package manager (dpkg over apt) is less secure if one has apt set up correctly.
Slackware (Score:5, Funny)
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
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.
Parent
Re:Compile from source yourself! (Score:5, Funny)
You've got him all wrong. He's a twelve year old with a PhD that reads and understand every line of code before he allows it to execute on his own hardware.
Parent
Re:Compile from source yourself! (Score:5, Funny)
Parent
Re:Compile from source yourself! (Score:4, Insightful)
Parent
Re: (Score:3, Insightful)
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.
Parent
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.
Parent
Re:Compile from source yourself! (Score:4, Informative)
Now you get your package management AND you get to compile from source. Best of both worlds.
Parent
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.
Parent
Re:Compile from source yourself! (Score:5, Funny)
Also, you have to trust your compiler, which you *had* to get from someone else.
Nah, I wrote my own compiler directly in machine code. I didn't trust my keyboard manufacturer either, so I tapped out Morse code on a homemade key. I made the BIOS out of coconuts, but that was just because that douchebag Gilligan said it couldn't be done.
-Roy Hinkley
Parent
Re: (Score:3, Informative)
The article actually discusses attacks that can be made by a malicious mirror even if you are only accepting signed packages.
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.
Parent
Re:The actual vulnerability (Score:4, Informative)
There is considerably more metadata than the filename in all package systems.
Although I generally only use RPM, I have seen enough of others to know that each package has information inside it that says things like "supplies foo-2.8.0.so". For example:
$ rpm -q --provides openssh
config(openssh) = 4.3p2-24.el5
openssh = 4.3p2-24.el5
This sort of metadata is part of the headers that are downloaded by the package manager to determine whether the system needs the package, and what other packages might be needed to fulfill dependencies. So, the system probably won't even download the file just because it was renamed. But, even if it does download it, when it tries to install it, you would get an error because a newer version of the capability (RPM term) named "openssh" is already installed.
You could always force the install, but no package manager does this sort of downgrade as an out of the box default
Parent
Re: (Score:3, Informative)
Re:Vendors sign with keys. (Score:4, Informative)
Considering Fedora (at least) signs all packages, seems like the authors should have been clear if the attack still works if the packages are not signed.
The article seemed pretty clear to me. The most vulnerable systems don't have signed packages or metadata or expiring signatures. The least vulnerable systems have all of those, but are still potentially vulnerable for a window of time before the metadata signature expires but after a vulnerability is found and fixed in a package.
Parent
Re:Vendors sign with keys. (Score:4, Informative)
They're saying that signing the package isn't good enough.
I think the threat they're describing is based on this idea: your Linux Vendor signs package foo-1.0. People being fallible, a security vulnerability is eventually found in foo-1.0. It gets patched. foo-1.1 comes out, and your vendor signs that too, and you install it. You are happy.
Then, one day, you tell your system to update everything. Your computer talks to some mirror, and gets a list of the latest packages. Then you download the latest packages. Oh look, here's foo-1.0. Oh good, it's signed by the vendor, therefore it's safe. You install it.
Oops, the mirror just tricked you into installing software with a known bug. The package was signed, but the information about what is the best package to download and install, wasn't signed.
Parent
Re:Vendors sign with keys. (Score:5, Informative)
What package manager silently downgrades packages?
I can see a package mirror (maliciously) refusing to stock updates, but yum at least picks a mirror at random by default. Apt didn't last I saw, but if you picked your own mirror, you already trust them.
Parent
Re:Vendors sign with keys. (Score:4, Informative)
But both Ubuntu and Debian have central security mirrors for security updates, which are added by default.
For this it doesn't matter (much) if a regular package mirror doesn't have the latest openssh, the security mirror will have one with the security fix in.
Now, there could possibly be some cases where security fixes gets published as regular updates where a replay attack could be successful. If the story would load off the apparently slashdoted web server, I could see if they had seen such issues, etc.
Parent
Re:Vendors sign with keys. (Score:4, Informative)
Ok, so foo-1.1 is uploaded on security.debian.org.
What are the official mirrors for security.debian.org ?
None. And if you decide to use some mirror anyway, try at least to select one you trust.
End result : everyone gets the patched foo-1.1
Parent
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.
Parent
Re:Hmmm (Score:4, Informative)
Parent
Re:Hmmm (Score:5, Funny)
Parent
Re:Neither (Score:5, Funny)
Parent
Re: (Score:3, Funny)
Re:Neither (Score:5, Funny)
I'm almost certain you didn't.
Parent
Re:Neither (Score:4, Funny)
Neither keep me up at night, I have a girlfriend and things to get done.
Perhaps you should consider changing your girlfriend, mine can always keep me up.
(for those without sense of humour up is used as erected)
Do you often find yourself having to explain your erections?
Parent
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]
Parent