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.

8 Responses to “0wning Arch: Why Package Signing Is Important”

  1. If this flaw has been known for 5 years, why hasn’t it been fixed?
    The main reason it hasn’t been fixed, as far as I know, is due to lack of developer resources and the complexity of how to manage the key.

    • They could learn from Debian. Debian developers are some of the most security conscious in the world. The “Strong Set” doesn’t exist, just because.

  2. Why hasn’t it been fixed? I’ll tell you why. Arch devs think they know better about the security of their packages than the rest of the world. It just boils down to pride.

    I’ve stated it many times, and I’ll state it again. There are only 2 reasons why I won’t use Arch:

    1) They don’t cryptographically sign their packages and package lists.
    2) They don’t separate the Free Software from the non-free.

    Fix those two issues, and they’ll have another user. In the meantime, Debian has been Doing Right for years, and it’s not likely that I’ll switch.

  3. What I’m immediately thinking of, is “how can we be sure the key we have is really the public key of the archlinux repositories ?”

    Maybe someone has played man-in-the-middle for that too.
    So, for this to really work, every user would need to meet an Arch developer to get the right public key.

    • Simple, the core developers each create their own GnuPG keys, if they don’t already have them. Then, they create separate signing keys as needed for parts of the operating system. Those signing keys get signed by the keys of the core developers. Immediately, a small Web of Trust is born.

      Then, each of the developers who maintain packages in the core repositories, each generate their own GnuPG keys, and begin signing their packages with their own keys. As developers meet with each other, they sign each others keys as well, including the operating system’s signing keys. The Web of Trust grows stronger.

      Because everyone has their own keys, everyone only has to worry about their own private key security. The only keys that become a major issue for the project are the project’s signing keys for the package lists. Some policies will have to be created to maintain tight control on its access and storage. But, it can be done right. Look to Debian for how they have implemented it.

      It really boils down to a decentralized system of developer keys and the Web of Trust. The PGP “Strong Set” consists almost entirely of Debian developers, because they meet as often as they can, at DebConf and other meetings, signing keys. As a result, the Strong Set is the largest and strongest Web of Trust in OpenPGP by far. There is zero doubt in my mind that when a signature checks out on a package, the package delivered to me is safe.

  4. Q: If this flaw has been known for 5 years, why hasn’t it been fixed?
    A: Because none of those people who have ranted about the lack of package signing have cared enough to get off their arse to do something about it.

    • This isn’t something you submit a patch to. The core developers have to create the signing keys, agree on its distribution and storage, and change they way they handle committing changed packages to the repositories.

      It’s not like I can create a GnuPG key for the operating system, “here you go”, and it’s done. Heh. There are steps and procedures that must be followed, and it has to start with the core devs and changes in their policies for something like this. The rest of us just have to wait, and see if they get it right.

  5. The Chakra Project is working on solving this issue as we speak with the new package manager akabei.

Leave a Reply to Aaron Toponce Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: