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 …

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

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

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

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

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

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

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

[Nate Amsden]

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)

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

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

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

[DropBear]

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.

[Nick Kew]

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

[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 :)

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

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

[A.P. Veening]

Re: "Supporting HTTP is fine,"

"Its 2018."

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

[Jamie Jones]

Re: "Supporting HTTP is fine,"

> Supporting HTTP is NOT fine.

Bollocks. Yes it is.

[Marcel]

Re: "Supporting HTTP is fine,"

It's even worse. It's 2019.

But yeah, no excuse to not use TLS.

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

[A.P. Veening]

Re: Its 2018....

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

[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 !

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

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

[Nate Amsden]

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

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

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

[bombastic bob]

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?

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

[randon8154]

Same as portage ?

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

[Hans 1]

?

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

[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 !

[Kiwi]

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.