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.

Comments

Depends on bugs in old software

[xZgf6xHx2uhoAj9D]

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:

1. the attacker finds some really old version of some software that they know to be buggy. E.g., they find OpenSSH version negative 5 or something, which had a terrible buffer overflow bug in it. This software has already been signed (years ago) by the package authorities
2. the attacker then sets up a mirror with only the broken version of OpenSSH on it
3. when a hapless Linux user goes to update OpenSSH, your mirror replies saying "the newest version is negative 5. See! I even have a 5 year-old certificate for it"
4. your client says "...oh...okay"
5. you install the old, buggy version of OpenSSH
6. the attacker has your IP address and knows that you downloaded (and presumably installed) the old version of OpenSSH
7. the attacker haxx0rz you

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

[99BottlesOfBeerInMyF]

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.

Sounds real and exploitable..

[moreati]

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

[drinkypoo]

It's easier just to firewall all new connections until updates are complete.

Re:Vendors sign with keys.

[kwalker]

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.

Re:Hmmm

[Anonymous Coward]

Your firewall won't stop this type of attack... RTFA.

Re:Vendors sign with keys.

[alrj]

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

Re:The actual vulnerability

[nabsltd]

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

Re:Well, sign the catalog then.

[Zero__Kelvin]

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.