Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Security Businesses Debian Red Hat Software The Internet Technology

Package Managers As Achilles Heel 263

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.
This discussion has been archived. No new comments can be posted.

Package Managers As Achilles Heel

Comments Filter:
  • Answer (Score:5, Funny)

    by Anonymous Coward on Thursday July 10, 2008 @06:57PM (#24144907)

    What keeps you up at night, the thought of attacks on your package?


  • by Krneki ( 1192201 ) on Thursday July 10, 2008 @06:59PM (#24144931)
    ... oh wait!
  • by speedtux ( 1307149 ) on Thursday July 10, 2008 @07:01PM (#24144953)

    I think a lot of these risks could be reduced if people downloaded from one site and verified against one or more other sites. Furthermore, if the checksums were verified over SSL, some attacks would be harder.

    Right now, verifying packages against a site other than the one they were downloaded from seems cumbersome with apt--or does anybody know of a simple command line to do so?

    • by DrYak ( 748999 ) on Thursday July 10, 2008 @08:51PM (#24146153) Homepage

      No need for anything as complicated as verifying packages accross several source :

      most modern package managers use key-signing on package.
      You can't setup a bogus repository and start serving malware to unaware users - those packages will fail the key check.

      For that to work, the crackers would also have to find a way to inject their own keys into the ISO of the distribution, and they'll have to find a way doing it that still pass the checksum of the peer-2-peer client with which the users downloaded the ISO.
      That might be possible with older p2p protocols relying on older weak hash, like eDonkey2k whose MD4 has known collisions, or even older protocols lacking checksums. (Some companies working for the media corporation back then used such possibility to pose as peer on the network and poisoning it by injecting bogus packets).
      But distribution currently rely on bittorrent which use SHA-1 hash and it's (currently) much harder to find a way to inject tampered data and have the resulting file still pass the checks.

      Another solution would be to trick the users into accepting a new set of keys to get onto the fake repository. For this, this repository will have to pose not as a mirror (as proposed in the TFA) but as an additional 3rd party repository hold functionalities not available in the original source (this is something that would benefit from the harsh imaginary-properties laws as most distro can't provide packages processing some media, and users have to rely on 3rd party repositories for this).

      Besides, the summary is misleading. They didn't actually setup a bogus mirror that served maliciously crafted files, or otherwise injected malware (that would be impossible given the signatures).
      They simply setup a mirror, that wasn't up to date on purpose, potentially exposing computer to exploit due to only older versions of software being updated.

      As actual legit mirror may lag behind the release, it is nevertheless preferable to always add the original repositories to the list of source : thus get the files from the mirror if available there, or straight from the original website if not replicated everywhere.

      This work around is even useful when there's no malicious intent.

      • by Zero__Kelvin ( 151819 ) on Thursday July 10, 2008 @09:17PM (#24146411) Homepage
        Actually, what they are saying is that they can set up a mirror with older packages that have known flaws in them and in effect downgrade you from having the latest security fixes to having one with vulnerabilities.

        The packages are still signed with an a valid key. They are just older packages rather than the latest ones.

        I have to give more thought to think if this will work, but I doubt that this has not occured to anyone else. I certainly thought of it before. Most likely the package managers have a way to keep this from happening already.

        Their entire Proof of Concept seems to be:
        1. We asked to be added as a mirror
        2. We succeeded without the distributions doing a cavity search
        3. A11 y0ur L1nux are b3l0ng t0 us!

        I wouldn't panick until I see a CERT advisory, or as someone else pointed out, at least one real world incedent.

      • by justin samuel ( 961189 ) on Thursday July 10, 2008 @09:18PM (#24146415) Homepage

        Just to be very clear about this one point because it is sensitive: the public mirrors we setup and had listed as official repositories were kept up-to-date and we only served current metadata and packages. We served nothing that was out-of-date (beyond normal mirror update lagtime between rsyncs with the upstream mirrors) and we served nothing that had been modified.

        All tests we performed related to what a malicious mirror could do (e.g. serving out-of-date metadata, serving modified metadata in the case of package managers that don't sign metadata, etc.) were performed using separate mirrors and clients of our own. Nothing we did with our mirrors put users at risk.

  • by xZgf6xHx2uhoAj9D ( 1160707 ) on Thursday July 10, 2008 @07:05PM (#24145003)

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

    • by 99BottlesOfBeerInMyF ( 813746 ) on Thursday July 10, 2008 @07:09PM (#24145061)

      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.

    • by blueg3 ( 192743 )

      Or, require the "list of most recent packages" to be signed, sign it with a timestamp, and have the package manager reject old package lists.

      There are plenty of other, more complicated schemes where packages known to have vulnerabilities could have their signatures invalidated.

    • by thatskinnyguy ( 1129515 ) on Thursday July 10, 2008 @07:34PM (#24145363)

      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 good and all until you download a bleeding edge version that is buggy as hell and want to go back to the old version.

      The simple fix is to change the update applications so that it never regresses (e.g., never installs software older than what it already has installed).

      • by tolan-b ( 230077 )

        Existing package managers won't regress unless you explicitly instruct them to. A standard apt-get update won't install older versions of packages just because they're in the list.

        As I understand the 'vulnerability', all they can do is keep you on an existing version known to be buggy, but if that's the case then surely they would already know you don't have the latest version because they've been getting their updates from you, so you don't supply it in the first place, then you hack them.

        Maybe I'm missing

    • Two minor points to object :

      - Current package managers don't downgrade automatically. (Yast will show the version numbers in red, but keep the highest version anyway).

      -People have at least 2 source for packages :
      1. a mirror of the distribution (containing all the packages)
      2. a "security" update website, which generally is also able to use delta-packages.
      some even add :
      3. the original repository, in case the mirror is lagging and doesn't have the latest version
      Under those circumstances, the packages manager

  • by heroine ( 1220 ) on Thursday July 10, 2008 @07:07PM (#24145033) Homepage

    The headline should be project managers as achilles heal.

  • by moreati ( 119629 ) <alex@moreati.org.uk> on Thursday July 10, 2008 @07:08PM (#24145041) Homepage

    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.


    • by jmorris42 ( 1458 ) * <jmorris@[ ]u.org ['bea' in gap]> on Thursday July 10, 2008 @08:22PM (#24145841)

      > One long term solution would be to sign package metadata and serve
      > it only from one central location, over https/sftp.

      Even that won't help. The authors got so caught up in the complex exploiting they didn't notice the BIG implication of their work. The problem can't be fixed with tech, crypto or anything but https connects to known to be trusted mirror operators.

      Follow along as I demonstrate. Spamgang wants zombies so they install a massive mirror farm for all of the major distros. They run it perfectly, fully updated with upstream as fast as their phat pipe can get it, perfectly signed metadata, packages and everything offered by http or https. Then they wait.

      Sooner or later another remote root bug, in openssh for example, will hit and they are ready. Thousands of machines either automatically connect or their owners see the story here on /. and hit the update button. They download that signed, correct metadata and sure enough their machines realize they need that new openssh package and ask the mirror for it. And are 0wned a few milliseconds later.

      Because in the act of requesting the package all those machines just told the spamgang that a specific IP is a) running openssh, b) it is the vulnerable version and c) that host is currently connected to the network and very likely has the vulnerable software running. So in the time it takes the updated package to transfer, unpack and install they have ample time to get in and install a rootkit. The beauty is that the victim will patch the hole and thus prevent anyone else from getting the zombie.

      Wait a random time before beginning to use the new zombies to help prevent people from getting wise to what is happening and the spamgang could likely get away with it for years.

      • by tolan-b ( 230077 )

        Thanks for explaining what I was trying to explain in another comment much better than I managed to.

    • by v1 ( 525388 )

      If the package manager simply refused to use metadata signed more than say, 3 months ago, wouldn't this help?

  • by spotter ( 5662 ) on Thursday July 10, 2008 @07:16PM (#24145153)

    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.

    • Re: (Score:2, Informative)

      by virtual_mps ( 62997 )

      More than that, Debian has a very limited set of security mirrors, and the default configuration points to a round-robin set of mirrors (so even if one of n was compromised and stopped serving updates, and nobody noticed--very unlikely--you'd only hit that mirror roughly one out of n updates).

      This article has all the hallmarks of a sensationalized report from someone either trying to impress people or generate page views. Sure it's relatively easy to add a relatively untrusted tertiary debian mirror, but th

    • Re: (Score:3, Interesting)

      by hweimer ( 709734 )

      If you use the Debian Security Analyzer [www.enyo.de], you cannot simply supply vulnerable versions of packages as they will still be listed by debsecan.

  • MD5 (Score:2, Redundant)

    by InlawBiker ( 1124825 )
    The summary is a little misleading because you can't just replace, say, 'ls' with 'exploit-binary-named-ls' because it'd fail the MD5 check. But a MITM constructed like they suppose could easily work. Briefly, it is:

    1. Set yourself up as a mirror
    2. Put old packages up with known vulnerabilities.
    3. Distribute "updates" listing the old packages as new updates.
    4. Watch your logs to see who updated with old packages, then go PWN them.

    It also counts on lazy admins, but garsh how rare are those.

    I guess

    • Then surely the key is not to get the current package list and md5 check from the same mirror that you download from.

      If source 1 says package x should be this version and with this md5 sum then a mirror offering a different version and different md5 sum shouldn't be trusted automatically.

      I don't think it would be too difficult to make the packaging system more robust than it is at present.

  • Yes, the vulerabilities are there. Not surprising to anybody that ever did a Debian mirror, for example. DNS spoofing already is enogh, not even a man-in-the-middle needed. Still, these are high-effort attacks. And with the IP addresses of the update servers used (instead of their names), MiM becomes neecessary. From my observations, MiM attacks oten need to be done in close physical proximity of the attacked machine. If somebody manages to get there, they can direcly manipulate my servers, with me possibly

  • by schwaang ( 667808 ) on Thursday July 10, 2008 @07:54PM (#24145589)

    TFA doesn't address Windows much. In the FAQ they say something like "since the vendor controls the repos for Windows and OSX, they are less vulnerable".

    True, I can't set up a bogus mirror for Windows -- except in a corporate environment, where I believe MS has some facility to allow a local cache of patches to reduce external bandwidth usage.

    But the authors keep talking about man-in-the-middle attacks on FOSS repos. Couldn't someone just as easily do that for Windows? And then use it to only offer outdated (known-vulnerable) versions of patches?

  • Slackware (Score:5, Funny)

    by FPCat ( 646737 ) on Thursday July 10, 2008 @07:55PM (#24145593)
    Good thing I'm running Slackware!
  • The metadata is signed as well as all the packages. This mitigates the situation, i.e. a malicious mirror cannot host arbitrary combination of packages to suit their needs, they must mirror some permutation that I had at one point approved all together.

    • Re: (Score:3, Informative)

      by XanC ( 644172 )

      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.

  • Forgive me for my lack of *nix prowess, but I've noticed that Package managers seem to be a predominantly Linux thing and unfortunately, I've not had the chance to get properly acquainted with the OS yet (I know, wtf am I doing here?). I've never encountered one in Windows, unless you count the handy package manager in DevC++.

    Are there any good windows alternatives, or is it simply not needed thanks to windows having many a dedicated installation packaging program?
    I wouldn't mind having one so I could get t

    • Oh and in case anyone complains, I already had a google around and could only find one project that hadn't been updated in about 2 years.

    • Re: (Score:3, Informative)

      by darkpixel2k ( 623900 )
      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
  • by rubberglove ( 1066394 ) on Thursday July 10, 2008 @08:04PM (#24145693)

    from the cert overview:

    Another potential solution to this problem is P2P technology. If widely used, programs like DebTorrent may allow official repositories to distribute metadata and tracker information while decreasing bandwidth costs.

    I wonder why Ubuntu doesn't make this a standard option. Is port forwarding too complicated? From what I understand, if the package is not available via bittorrent, DebTorrent degrades to using http.

  • It's a true risk. (Score:3, Insightful)

    by drolli ( 522659 ) on Thursday July 10, 2008 @08:06PM (#24145703) Journal
    It is really risky not to have a revokation mechanism for packages, but definig this by availability of a new package somewhere. The only solution would be to have servers, which contain a list of revoked packages. If connecting to these list fails, the update should stop.
  • Except that it is solved by MD5 checksums as noted by several people. A sophisticated attack of this nature would require being added as a mirror, accepted by your target as being genuine, and then taking on the provider of the checksum to provide a false one.

    Of course, someone might take the time to develop a package with the same checksum as the actual file I suppose, but it has been so long since I've read up on encryption that I don't know how feasable this is. Anyone else? I'm fairly certain that by th

  • by Robbat2 ( 148889 ) <robbat2@orbis-terrarum.net> on Thursday July 10, 2008 @10:05PM (#24146893) Homepage Journal

    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 [livejournal.com]

  • by Sun ( 104778 ) on Friday July 11, 2008 @01:54AM (#24148715) Homepage

    As far as I can tell, Debian is not vulnerable in its default install mode.

    a - Debian will never automatically downgrade a package.
    b - Security problems (as opposed to mere changes) get published in the Debian security repository.
    c - The Debian installer automatically adds the debian security mirror to the end of your sources file.

    So, you can create a mirror, easily inject it into the list of official Debian mirrors, and freeze the packages offered on it. You can do all that easily. It won't help you. If you take the CERT example, of the vulnerable openssl package, the fix was pushed through the security repository, and that is added by default to all new Debian installations. The attack would fail.

    Furthermore, even if your mirror offered a security mirror as well, I, personally, always keep the Debian source as well, lower in the list. This way, if the local security mirror is up to date, I take stuff from there. If it's not, I take it from the Debian server. This means that even if you deviate from the default behavior, you can still be not vulnerable.


  • Slackware (Score:3, Insightful)

    by ledow ( 319597 ) on Friday July 11, 2008 @06:00AM (#24149955) Homepage

    There seem to be a lot of distributions whose package managers rely on the keys/hashes to "secure" the packages, where the mirrors are providing those keys/hashes. Silly idea - always has been, what makes this news?

    What this article is basically saying is "anyone can be a mirror" (Yes, that's the point, without that you wouldn't be able to get a release/security update for ages after its release, or you could just take one website offline and stop all package updates worldwide - both are worse for security than the alternative) and "some package managers don't properly check the authenticity of a package from a mirror". The second is a problem that's easily fixed and shouldn't be present, granted. What idiot would accept a valid signed package without first checking that the root key it's signed with isn't current, valid and not revoked? This is like your web browser navigating to random SSL websites without first checking that the certificate chain is correct and valid and ends in a trusted root.

    1) Download key from "redhat.com" or wherever (DO NOT USE MIRRORS), or from the CD, on first install.
    2) Everytime you are asked to fetch a list of available packages, check the authenticity of that key against "redhat.com" directly (DO NOT USE MIRRORS), check the expiry date, check for revocation information, or allow the user to override (their fault), or check public keychains.
    3) If the key ever changes, ALERT THE USER before you do anything with it (don't try and get smart by signing a package with the old key that introduces the new key to the world, or automatically accepting a new key). Then the distribution should NEVER use that old key ever again, and maybe even resign all old packages with the new key.
    4) Use that key to verify all packages downloaded from any mirror against the GPG signature from that package (for ultra-security, get that from a second, random mirror, or the official website).

    There's a small window of opportunity for compromise on machines that install packages without checking first, or assume that because a key was once valid it always will be, or are significantly out of date and don't check the "definitive" source for a new key first but you'll never remove that completely. The way to do that is to check the root key, reliably, on a regular basis. But then if you have an old machine that still has the key from the install CD, and that key is compromised, and the machine does not have reliable (read SSL with significant trusted chain) means of contacting the main server without possibility of spoofing for a new key, then you have a problem.

    I don't see why this is "news" or even vaguely important except to show up distros that aren't ALREADY doing it this way.

    BTW: This is why I do package management on Slackware using a script that makes *me* get the GPG-KEY from slackware.com first if it ever changes (including checking if the IP of ftp.slackware.com has changed, the date of the file has changed, the key itself has changed etc. but if they can compromise my access to Slackware.com without hitting one of those checks, I'm stuffed anyway), why I have an RSS feed of Slackware and check the website myself regularly (just in case the key requires changing and news is posted about it), why I only use trusted mirrors, why I download the GPG signature and package from seperate mirrors and why nothing gets installed without that GPG check succeeding. To be honest, I see this just as being sensible for anything that goes into production. I'm still waiting for a rogue Windows Update, but it surprises me that some distros (or administrators) don't ALREADY do all this...

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein