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.
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).
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
The article actually discusses attacks that can be made by a malicious mirror even if you are only accepting signed packages.
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.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
Thanks for reading the article.
The point is that there are plenty of signed (but old and vulnerable) packages that can be given to your system that it will gladly accept leaving you open to attack.
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
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.
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.
... And so it comes to this.
Your firewall won't stop this type of attack... RTFA.
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
...exactly what happened to PHP a couple of years ago.
But the general theme this post rings is: in FOSS, if you don't (as hardly any end user does) inspect the source code, know and trust the origin.
It won't be long before those who write `malware' will start searching for ways to get hold of linux desktops. And for them, prospects aren't that promising with blunt exploits against whatever is running on your linux desktop with some ports open. Neither, I earnestly hope, will an average linux user be so outright... er... end-userish as to go happy-clicking on links in spam.
Instead, setting up or overtaking some ftp.xx.debian.org is only sensible and effective to this end.
For anybody interested on this in Gentoo, I have updated my GLEPs about signing the portage tree to include a Gentoo-specific solution for this, by distributing a copy of the top-level signatures by a trusted system:
http://robbat2.livejournal.com/226512.html
ICQ# : 30269588
"I used to be an idealist, but I got mugged by reality."
It's also plausible that a package manager could be compromised. It's unlikely with a major distributor like Canonical, Redhat, Novell, etc. but more likely if you use third party repositories.
Packages managers put one more link in the security chain. In most cases, it's probably not the weakest link, but it does add one more vector for attack.
Don't get me wrong. I use Ubuntu because of the package management. I could get slightly better performance if I compiled everything for my specific processor, and it would be a better security practice to compile my own packages, but for my personal systems the convenience of being able to say "install this package" outweighs the benefits of compiling everything myself.
But the malicious mirror also has a steady stream of data coming in, which includes IP addresses of people running vulnerable services, and which services those are. Before the patch is finished installing, the user is rooted.
Are there any good windows alternatives, or is it simply not needed thanks to windows having many a dedicated installation packaging program?
There really isn't an equivalent in Windows. I would imagine that it's because Linux is very modular, and almost all the software is free. Windows developers charge money and want you using their installer which (in some cases) requires license keys, etc...
It would be cool though if someone build a front-end for the Windows Installer (msiexec) that would let you 1-click download and install some of the open-source apps out there that are packaged as MSIs. (Think OpenOffice, Java, etc...)
There's no place like
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
BSD Ports
Now you get your package management AND you get to compile from source. Best of both worlds.
Me failed English...
FreeBSD over Linux. If my comments seem odd, this may explain...
I guess keeping the "Interesting" mods is OK so I won't request that they be removed (though I would understand if someone throws a few "overrateds" at me), however I misspoke. Someone else pointed out that the package files, such as yada-yada-2.6.7.myarch.rpm have the important metadata in them already, it is signed, and changing the filename doesn't change the dependency information therin, so there is no vulnerability, and this is much ado about nothing. I stand corrected, and should have stayed with my original post on the matter.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
This is one of the advantages of something like the BSD ports system. You download the entire ports tree, which contains recipes for building every package. When you get the source, you typically get it from the upstream host (e.g. sourceforge), but they have no way of knowing whether you are running that program, installing it for the first time, or simply grabbing the source to build packages for deploying on other machines.
I am TheRaven on Soylent News
If I'm not mistaken, using Debian you can grab source packages as opposed to binaries simply by running apt-get source packagename rather than apt-get packagename
In yum (which I will assume you are using since it's the most popular RPM based package manager and you refer to rpms) there are no signatures on the repository metadata or package metadata. There are signatures on the packages themselves, but not the extracted package metadata.
The fundamental way the replay attack works is that I can have my mirror host outdated versions of packages that are correctly signed. I can use an old repository metadata file or write my own repository metadata file that refers to package metadata and packages that are out of date. A client may ask to install firefox and I would provide a correctly signed version of firefox-2.0. Clearly if this package contains a vulnerability that I can exploit remotely, I now can control your system.
The fact that the package metadata in the tarballs isn't signed also enables some other attacks. Yum will blindly trust any package metadata it receives. So when you download the package metadata for firefox, I can modify the package metadata to say it depends on additional packages (which will cause you to install them as well), say that it has a dependency on a package that does not exist (which prevents you from installing firefox at all), or return a huge list of packages to attack another repository (details on website / papers). Yum does not check any signature until after it finished dependency resolution and downloads all of the packages.
Surprisingly yum does not verify that the package metadata it received from the repository matches the metadata embedded in the signed package. So if I say firefox depends on apache (both packages correctly signed), yum will install both even though after downloading it could check the firefox RPM to see it doesn't depend on apache.
We think that the right way to tackle this problem isn't to sign the package metadata, but the repository metadata. Since the repository metadata has the secure hash of the package metadata (in most repository layouts), signing the repository metadata covers all of the content on the mirror / repo. We advocate using timestamps and expiration times to prevent an attacker from providing an older but correctly signed version of the repository metadata or freezing the metadata perpetually. (please see our papers for more information)
Anyways, we understand the skepticism and appreciate the spirited emails and slashdot comments we've received about these vulnerabilities!
Justin Cappos
(*) Not all package managers download package metadata in separate tarballs (some actually scrape information from the headers of the packages on the repository). Regardless of how the information is stored, if it's not signed then an attacker can substitute malicious data. I'm simplifying here to make the discussion clearer and more generally applicable to a wide range of package managers.
As an aside, here's the famous "don't use kill -9" letter:
No no no. Don't use kill -9.
It doesn't give the process a chance to cleanly:
1) shut down socket connections
2) clean up temp files
3) inform its children that it is going away
4) reset its terminal characteristics
and so on and so on and so on.
Generally, send 15, and wait a second or two, and if that doesn't
work, send 2, and if that doesn't work, send 1. If that doesn't,
REMOVE THE BINARY because the program is badly behaved!
Don't use kill -9. Don't bring out the combine harvester just to tidy
up the flower pot.