back to article Heads up: Debian's package manager is APT for root-level malware injection... Fix out now to thwart MITM hijacks

The Debian Project has patched a security flaw in its software manager Apt that can be exploited by network snoops to execute commands as root on victims' boxes as they update or install packages. The Linux distro's curators have pushed out an fix to address CVE-2019-3462, a vulnerability uncovered and reported by researcher …

  1. Anonymous Coward
    Anonymous Coward

    "Supporting HTTP is fine,"

    For fucking fuck's sake !

    Supporting HTTP is NOT fine.

    Its 2018.

    Every coding language and its dog can speak HTTPS, or if it can't, there will probably be a million libraries to choose from to tell it how to speak HTTPS.

    HTTPS doesn't put any strain whatsoever on processors (or even 10 year old processors).

    And with the advent of LetsEncrypt, cost isn't an excuse any more either, nor is having to worry about renewals ... its all automated.

    And for those idiots serving their package repos over HTTP, going HTTP means you can't have HTTP2.

    I know Google deservedly deserves all the hate going their way, but turning-on that "show semi-warn thing if HTTP" was actually one of the few good things they did for the greater internet. It encouraged a hell of a lot of lethargic webmasters to pull their heads out of their backsides.

    1. Anonymous Coward
      Anonymous Coward

      Re: "Supporting HTTP is fine,"

      https is already supported, just not by default... plus, http is easier to cache.

      But yes, it should be enabled by default.

      1. Anonymous Coward
        Anonymous Coward

        Re: "Supporting HTTP is fine,"

        What do you need to cache for ? All the distros allow you to clone their repos. If caching is a big deal for your network, just clone and serve in-house.

        And yes, HTTPs should be the default.

        1. Alex Brett

          Re: "Supporting HTTP is fine,"

          You can try and clone the Debian repos, but you'll be there a *LONG* time (e.g. the amd64 archive is currently 327GB - see https://www.debian.org/mirror/size) - a caching HTTP proxy avoids needing to download such huge amounts of data.

          To be fair, you can achieve HTTPS using something like apt-cacher, which is essentially a caching proxy that understands the structure of a repository and can have the upstream repos configured directly into it, so you could talk HTTPS to it from your hosts, and then it could talk HTTPS to the upstream repos, but that's extra infrastructure that I can understand people who already have a caching HTTP proxy may want to avoid.

          1. Anonymous Coward
            Anonymous Coward

            Re: "Supporting HTTP is fine,"

            "but you'll be there a *LONG* time (e.g. the amd64 archive is currently 327GB - see https://www.debian.org/mirror/size)"

            People who actually have genuine need to concern themselves with the concepts of caching or cloning will most likely have pipes large enough to make light work of 327GB.

            Even on a "small" 100Mb pipe, 327GB is only seven hours and so you could fire that up on a quiet evening or weekend sometime, and let's face it, most people who have a genuine need to think about caching or cloning will have something a bit bigger than 100Mb at their disposal (e.g. on 1Gb, 327GB is only 46 minutes and on 10Gb its just under five minutes).

            If you're just a small office with one or two server boxes hanging off the back of an ADSL connection, you probably have better things to worry about than either caching or cloning.

      2. Scott Wheeler

        Re: "Supporting HTTP is fine,"

        apt supports HTTPS (by changing the URLs in /etc/apt/sources.list and /etc/apt/sources.list.d/*). However that doesn't mean that the web servers ("apt data sources") that those URLs point to actually implement HTTPS. Certainly the default servers for Ubuntu for a UK user do not support HTTPS.

    2. dfsmith

      Re: "Supporting HTTP is fine,"

      Using HTTPS (rather than HTTP) means than an external observer (e.g., your friendly network admin) cannot detect that your machine is retrieving indexes with invalid signatures. Uh oh!

      This message brought to you by the Department of Implausible Contrary Scenarios.*

      * Acronym now 20% more funny.

    3. Nate Amsden Silver badge

      Re: "Supporting HTTP is fine,"

      because hosting it on https makes it totally secure right? HTTPS protects against some things, but introduces extra complexity(good luck troubleshooting when you don't have the SSL key) and performance hit(can be huge depending on your settings for a site shoveling as much data as debian's mirrors likely are - that and they are mirrors after all). I'm all for making https an option though for those that are super paranoid.

      There seems to be approx 418 mirrors on debian's site https://www.debian.org/mirror/list if my quick checks map out. Of those I see about 177 valid HTTP responses on https ports. I did not attempt to do anything other than view the debian directory(with wget, and I told it to not to validate the certificate since wget doesn't know all CAs. There were ~80 SSL cert errors reported ranging from unknown CA to expired cert to "no certificate subject alternative name matches").

      Personally I'd be more concerned about people hacking into debian's systems (or even the mirror you're connecting to) and uploading bad packages than I would ever be of someone doing a MITM on one of my systems. I think overall the chance of a real problem is VERY low for most people. No reason to freak out, but freaking out generates the headlines I guess.

      (Debian user since 1998 - though switching to Devuan)

      1. Anonymous Coward
        Anonymous Coward

        Re: "Supporting HTTP is fine,"

        Debian graybeards caught with the pants down, insisting nothing had happened... LOL!

        What would have you written if something alike had happened in Windows Update?

        Evidently the mechanism to ensure packages origin over HTTP is not strong enough.

        And remember - packages can execute code when deployed... in this case with root privileges.

        But all is fine, because Debian is secure because it is secure, as in "we say is secure, and no proof is needed - god made it secure in the beginning of times".

    4. Anonymous Coward
      Anonymous Coward

      Re: "Supporting HTTP is fine,"

      Aren't the packages checked against signed checksums (by the distribution)?

      Any MITM change should be detectable, as checksum does not match (and if you try to change the checksum file, the signature will not match).

      The debian security does not depend on package transfer being over HTTPS, HTTP is equally safe.

      1. msa

        Re: "Supporting HTTP is fine,"

        ... should have read the report. The vulnerability is a bug in signature checking process, so a patching is needed. Blah...

        1. DropBear Silver badge

          Re: "Supporting HTTP is fine,"

          The article does not compute. Either the packages and the signatures are protected by public key signatures in which case you either stole Debian's private key or it doesn't matter how MITM you are, or they are protected by mere hashes, which would be insanity of intergalactic proportions for the last twenty years or so. Not sure which it is, but both cases make zero sense.

          1. Nick Kew Silver badge
            WTF?

            Re: "Supporting HTTP is fine,"

            I'm shocked at Reg commentards. Just one of you points out the obvious, and 7 hours on I seem to be the first to notice.

            The article says

            And the hacker would be able to control the hashes used by Apt to check the downloaded package,

            which would indeed imply a complete absence of cryptographic protection.

            I know apt in reality uses PGP signatures. My best guess is there's a bad bug in their usage, but the details went so completely over the journos head we got this incoherent nonsense.

            Or maybe it really did use PGP keys as checksums with no WoT? Surely not. Must find coherent report on the subject. Aha - there's a comment below from someone who has looked and understood (or else bullshits well enough to convince me).

      2. Anonymous Coward
        Anonymous Coward

        Re: "Supporting HTTP is fine,"

        "Aren't the packages checked against signed checksums (by the distribution)?"

        Yes, they are, but the checksums are equally unsafe, because ... they're downloaded via HTTP :)

        1. nagyeger

          Re: "Supporting HTTP is fine,"

          Yes, they are, but the checksums are equally unsafe, because ... they're downloaded via HTTP :)

          But the checksums are in files which are themselves digitally signed, aren't they? That's why you can't just start using any old repo, but need to tell GPG about the repository signing key too.

          And the public key arrives over https, from a keyserver.

          Are they saying that despite requiring a key they're not using it properly? I don't understand...

          1. nagyeger

            Re: "Supporting HTTP is fine,"

            Oh.... just read the original problem report... It's NOT tampering with the checksums, it's bypassing them, because (A) the inter-process channel (between apt-aquire and apt) quotes some progress stuff literally from the HTTP communication. and (B) the signature file can include pre-signature junk. e.g. an entire .deb!

            Thanks to the extra junk in the channel, the master process gets fed the wrong signatures and dpkg gets told to install the signature file not the verified package, and I guess it ignores the trailing signature.

            So it's really an out-of-band data / injection attack that sneaks in an extra payload after the cryptographic checks have passed, and it basically means that someone controlling a mirror can inject anything she likes to her users.

            To my mind the roles of master/worker roles probably need rethinking, so that the type of filename replacement used here and such-like aren't possible in future versions, not to mention that the downloader shouldn't be responsible for only half of the security checks.

    5. A.P. Veening

      Re: "Supporting HTTP is fine,"

      "Its 2018."

      Wrong, it is 2019 (and has been for more than three weeks now).

    6. Jamie Jones Silver badge

      Re: "Supporting HTTP is fine,"

      > Supporting HTTP is NOT fine.

      Bollocks. Yes it is.

    7. Marcel
      Linux

      Re: "Supporting HTTP is fine,"

      It's even worse. It's 2019.

      But yeah, no excuse to not use TLS.

  2. Anonymous Coward
    Anonymous Coward

    Its 2018....

    Yes, before a smart alec comes along. I spotted that typo but my edit period had run out !

    The fact its actually 2019 makes my post even more poignant. ;-)

    1. A.P. Veening

      Re: Its 2018....

      Sorry, your correction had sunk out of sight by the time I replied.

  3. Anonymous Coward
    Anonymous Coward

    Lousy advice guys

    Tried it on one of my Debian machines:

    "sudo apt update -o Acquire::http::AllowRedirect=false"

    "Failed to fetch http://security.debian.org/dists/jessie/updates/main/source/Sources 302 Found [IP:]"

    "Failed to fetch http://security.debian.org/dists/jessie/updates/main/binary-amd64/Packages 302 Found [IP:]"

    "Some index files failed to download. They have been ignored, or old ones used instead."

    Sounds like a catch22 to me !

    Well done Debian !

    1. drankinatty

      Re: Lousy advice guys

      For my debian installs,

      sudo apt update -o Acquire::http::AllowRedirect=false

      worked fine, but...

      sudo apt upgrade -o Acquire::http::AllowRedirect=false

      resulted in

      Err ... 302 Found [IP: 93.93.128.193 80]

      Changing to a fixed mirror in /etc/apt/sources.list will fix it. (see: https://www.debian.org/mirror/list for one near you)

      1. Anonymous Coward
        Anonymous Coward

        Re: Lousy advice guys

        "Changing to a fixed mirror in /etc/apt/sources.list will fix it"

        Well maybe it will, but that's not quite the same thing as Debian's "just run these two one-liners and it'll be all ok".

        Sure for me as experienced user changing mirror's in source.list is no problem.

        But what about joe-schmo .... Debian shouldn't be pretending the fix is as simple as a couple of apt option flags.

        1. Nate Amsden Silver badge

          Re: Lousy advice guys

          Shouldn't be anyone who is not experienced or at least not willing/eager to dive deeper into linux using something like Debian. For those folks anyway this specific thing mentioned in the article is a non issue to begin with.

          I started with Slackware 3.something back in 1996(instead of Red Hat which was the only other option I was aware of at the time) specifically because I wanted to get more into Linux. Went off building(eventually) my own kernels, libcs, X11s, gome, KDE, whatever. Red hat of course you could/can do the same though the lack of a similar formal testing/package repo to me at the time at least meant I didn't want to use it.

          Tried Debian in 1998(Debian 2.0) by recommendation of someone I knew online at the time. Still remember spending 2-4+ hours i dselect(oh the pain) choosing packages those first few times I installed. apt-get came later(debian 2.2 ?). Ironically enough I still find dselect vital these days for just 1 reason (dpkg --get-selections and dpkg --set-selections makes things very easy when building new similar systems (that don't otherwise have/need massive automation, such as my personal servers, laptops, desktops - the latter run Mint which is still Debian based).

          1. Scott Wheeler

            Re: Lousy advice guys

            > Shouldn't be anyone who is not experienced or at least not willing/eager to dive deeper into linux using something like Debian. For those folks anyway this specific thing mentioned in the article is a non issue to begin with.

            No - this presumably affects Ubuntu and other distros downstream of Debian.

      2. Anonymous Coward
        Anonymous Coward

        >Changing to a fixed mirror in /etc/apt/sources.list will fix it. (see: https://www.debian.org/mirror/list for one near you)

        Could you elaborate on that? I'm using "deb http://ftp.uk.debian.org/debian/ jessie main non-free" which seems to be in that list but am still getting errors.

      3. bombastic bob Silver badge
        Unhappy

        Re: Lousy advice guys

        "Changing to a fixed mirror in /etc/apt/sources.list will fix it."

        how about FIXING sources.list to use https???

        I tried this on a Devuan system...

        apt-get install apt-transport-https -o Acquire::http::AllowRedirect=false

        it gave me the re-direct error. So I installed without the '-o' part. should be ok, it's my normal connection.

        then I changed sources.list to use 'https' instead of 'http'. problem solved? NO.

        I kept getting server cert verification errors, and 'ignores' and whatnot. Using various incarnations of 'Verify-Host=false' and 'Verify-Peer=false' didn't seem to help.

        since I don't have a debian install any more, can anyone get this to work on THEIR systems?

    2. Anonymous Coward
      Anonymous Coward

      Re: Lousy advice guys

      You appear to be running the old-stable 'Jessie' release, which is now on LTS

      FYI:

      https://wiki.debian.org/LTS

      "Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS will not be handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.

      Thus the Debian LTS team takes over security maintenance of the various releases once the Debian Security team stops its work."

      It would appear that the LTS team haven't back-ported the fix from 'Stretch' yet.

  4. randon8154

    Same as portage ?

    It remind me https://security.gentoo.org/glsa/201507-16

  5. This post has been deleted by a moderator

    1. Anonymous Coward Silver badge
      Windows

      Are you suggesting that we should port BITS and wuauclt to Linux?

  6. Hans 1 Silver badge
    FAIL

    ?

    So, the guy needs to MIM you, redirect your apt-get requests to his site, ok, but ... how does he sign packages ? I mean, those are signed by the distribution ? Has he got a copy of the private key of our distribution ? Wow, then we have other problems, because he no longer needs to MIM us ... he has access to the build servers ...

  7. M0PLT
    Boffin

    HTTPS is expensive!

    Many of the free mirrors exist because it is a very simple process to rsync directory trees and offer them out via http, ftp, and rsync. Take a look at Kent University's mirror service as an example. Packages are digitally signed, so an insecure download of a signed package does not remove the protection; and an incorrectly signed package should cause the package manager (apt-get/yum/dnf) to baulk. Switching to https to serve huge mirrored resources will require more administration, configuration and management; and the purchase and management of potentially hundreds of digital certificates - depending on how the mirror wishes to operate, and how the package managers handle the Common Name in the certificate.

    1. Anonymous Coward
      Anonymous Coward

      Re: HTTPS is expensive!

      "Switching to https to serve huge mirrored resources will require more administration, configuration and management; and the purchase and management of potentially hundreds of digital certificates"

      You need to update your SSL knowledge as you are stuck in the dark ages somewhere in 1990 !

      Go read up on the ACME protocol, LetsEncrypt and a few other 21st century inventions.

      Or just use Caddy as your web server and you hardly need to read up on anything at all. All the "difficult" SSL stuff is automagically done for you.

      Once you've read up on the above, I dare you to come back and complain its still admin and financially intensive to manage HTTPS in this day and age !

      1. M0PLT
        FAIL

        Re: HTTPS is expensive!

        You are still suggesting that every mirror operator around the world expend considerable effort and financial cost changing how their systems operate to suit your "21st century" solution. Remember these mirror servers could be handling thousands of requests per second on gigabytes of data. They are not your two-bit "mom-and-pop" shop who can get away with minimal resources whilst not caring what ciphers the latest fad of a web-server is offering. Cheap security is still no security!

        1. Kiwi Silver badge
          FAIL

          Re: HTTPS is expensive!

          Remember these mirror servers could be handling thousands of requests per second on gigabytes of data. They are not your two-bit "mom-and-pop" shop

          If they have the resources to pay for that, they have the resources to pay for someone who knows what they're doing.

          If my "mom and pop" setup took only an hour or less to install and run basically automatic software that configures the server (using industry standards, not "the latest fad") and does the rest for you, they can do it. Their testing/approval requirements may be larger, but they have more resources to put into it.

          These guys aren't some mom-and-pop dime store where the website exists only to show where they are, when they're open, and what they sell. These guys are handling a pool of software that much of the world's critical infrastructure runs on.

  8. Anonymous Coward
    Anonymous Coward

    OMFG I TRUESTED THEM NOT TO DO STUPID SHIT LIKE THIS

    Anon because I don't want my anger to backfire....

    But what the fuck!?! This would be so easy to exploit (albeit requiring updates to be MITMed too) when you download bad hashes in the first place - WTF APT? Why do you even bitch about me adding keys in the first place? (actually that's a good point - I should finish the article)

    STILL!

    It's actually not mentioned.... I guess this is for unsigned repos? Anyone have any information?

    1. Kiwi Silver badge
      Trollface

      Re: OMFG I TRUESTED THEM NOT TO DO STUPID SHIT LIKE THIS

      Even worse, you have to wait till a Tuesday next month before you can even get a patch for it.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019