0wning Arch: Why Package Signing Is Important

Arch Linux is a popular linux distribution aimed at power users. It allows a great deal of customization, providing a minimal core system from which the user can build off of. Arch is normally a security conscious distribution, with a rolling release system and simple tutorials on the wiki outlining how to enable full disk encryption and switch Linux password hashing from md5 to sha512. However, the Arch Linux package manager, pacman, seems to be an exception to this general security consciousness. This is because pacman uses neither a signed package list nor signed packages when upgrading or installing new software. The only check pacman makes on the integrity of a software package is that the package’s md5 checksum matches the checksum listed for that package in the package list. This makes exploiting an Arch system almost trivial provided an attacker is able to place themselves between the Arch system and the Arch package repository. For those unfamiliar with why package signing is so important to the security of a Linux system, I will outline the simple steps an attacker would have to take to gain root privileges on an Arch system using only this flaw in pacman. To be clear, unless you completely trust every network you’ve ever updated your Arch system on, you’ve potentially been 0wned.

Subverting an Arch Package:

Making alterations to an Arch package (at least well enough for pacman not to throw up errors) is EXTREMELY simple. I was lazy and simply opened my chosen package (gzip) up in file-roller and editted the “.INSTALL” file. I chose to alter the gzip package because it’s in the core repository which virtually everyone will be using, it’s a very small package, its functionality almost never changes (it’s nearly 20 years old), and it already contains a “.INSTALL” file to alter.

In the “.INSTALL” file I added a single line to the end of the “post_install()” function, which was “mkdir /U_HAVE_BEEN_0WNED”. This just creates a directory at the filesystem root called “U_HAVE_BEEN_0WNED”, but I could just have easily told the script to run wget and grab some malicious script or have created another user or uploaded /etc/shadow and/or any ssh keys to myself. Or I could have run “rm -rf /” if I just wanted to watch the world burn. The command runs as root so the options are pretty much limitless. I also changed the package version number in the filename and “.PKGINFO” file (from 1.4-2 to 1.4-3 in my case) so that it would be seen by pacman as a newer version and offer to upgrade.

At this point astute observers are probably saying “Wait, since you altered the package, the md5 checksum of the package no longer matches the package list. Won’t pacman ignore it?”

Yes. Which is why we’re also going to alter the package list, which isn’t signed either. Again, this is a trivial process. I just downloaded the core.db.tar.gz file, opened it up in file-roller (because, again, I’m lazy) changed into the gzip directory and altered the “desc” file so that the FILENAME, VERSION and MD5SUM parameters matched my modified package.

Mirroring Evil:

The next step to 0wning an Arch box with no known vulnerabilities (other than pacman and the human behind the keyboard) is to set up a mirror to host the modified package list and package(s). I used vsftpd, making sure anonymous downloads were enabled. The Arch mirror directory structure is simple enough; package lists and packages sit in the same folder, which uses the naming structure “archlinux/{core|community|extra}/os/{i686|x86_64}/” depending on which repository is being requested. Place the packages and package lists in the i686 or x86_64 directories, depending on your architecture, and you’re done.

Again, astute observers will notice that at this point we need to get the target Arch system to use our mirror. Why would they do that? Naturally, any security conscious person wouldn’t do that. So we’re going to trick the machine into thinking that WE ARE their usual mirror.

Playing Monkey-In-The-Middle:

At this point, we need to get the target Arch machine to connect to a network that we either control (using a rogue access point, for example) or that we can perform ARP cache poisoning on. At this point, ettercap is your best friend. I won’t go over its usage here, that’d take much too long. I will simply say that once we’ve poisoned their ARP cache, we’re going to perform a DNS spoofing attack and impersonate the package mirror our target Arch machine uses. At this point, all we do is wait for them to check for system upgrades. Running “pacman -Syu” will download our altered package list and show our altered package(s) as available upgrades. Upon upgrading, the user will see nothing out of the ordinary, there is no indication that any packages were untrusted or anything like that. They’ve been 0wned, and they are none the wiser.

Fixing the Problem:

In the long term, the only real fix is to implement proper signing for both packages and the package list. However, security can be greatly improved right now by simply signing the package list. This would eliminate the ability of attackers to fake an update when one is not available, and would require an attacker to craft a malicious package with an identical md5 checksum to the legitimate package it seeks to impersonate. So, as previously stated, the obvious first step is to begin signing the package list as soon as possible. Once this is accomplished, signing for all packages should also be implemented.

Q & A:

Q: Why would you write this? Doesn’t this put Arch users at risk now that anybody can find out how to compromise an Arch machine?
A: This flaw has been known to Arch and pacman developers since at least 2006, possibly earlier. It’s been 5 years. It’s time for a proper fix. Hopefully this will push things in the right direction.

Q: So if Arch switches to a better hashing algorithm than MD5, will that fix the problem?
A: No. This vulnerability has nothing to do with the strength of MD5. Packages using SHA512 checksums would be equally vulnerable. The problem is proper signing of packages and, most importantly, the package list.

Q: What can Arch users do to keep themselves safe in the meantime?
A: Only download packages from trusted mirrors over trusted networks. A tool like paccheck may be useful, but only if the attacker hasn’t dns spoofed all the mirrors, which is entirely possible and not difficult to implement.

Q: If this flaw has been known for 5 years, why hasn’t it been fixed?
A: I can only assume it hasn’t been fixed due to lack of developer resources, interest, and knowledge of how big a problem this actually is.

~ by f1ngerscr0ssed on March 17, 2011.