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
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.
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
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.