Remote code execution vulnerability in apt/apt-get • Hacker News Board

Re: Remote code execution vulnerability in apt/apt-get

#141

Post by explainplease » Wed, Jan 23, 2019, 12:22 AM UTC

deathanatos wrote: post #135

explainplease wrote: post #122

$ sudo sed -i 's/http:/https:/g' /etc/apt/sources.list $ sudo apt-get update ... Err https://us.archive.ubuntu.com trusty/main Sources Failed to connect to us.archive.ubuntu.com port 443: Connection refused ... Err https://security.ubuntu.com trusty-security/main amd64 Packages Failed to connect to security.ubuntu.com port 443: Connection refused ??? $ curl -v https://security.ubuntu.com/ubuntu/ * Hostname was NOT fo…

As was discussed recently on HN (and linked to elsewhere in the comments for this article), packages are signed, and APT checks those signatures; however, APT does download both the packages and the signatures in the clear. So, normally, the signatures get checked, which ensures that you get the package you intended. This is fine, mostly. (If you don't care about privacy , but it does prevent tampering, normally.) AP…

I think you misunderstood my comment. I'm aware of the apt security model and the nature of this bug.

My point is that these Ubuntu repo servers are not available over HTTPS, which seems like a problem. In the context of this bug, a serious one--who's to say that there aren't more bugs like this lurking? There's no reason that these servers shouldn't be available over HTTPS.

Re: Remote code execution vulnerability in apt/apt-get

#142

Post by NicoJuicy » Wed, Jan 23, 2019, 12:33 AM UTC

vvanders wrote: post #80

Sephr wrote: post #55

Using HTTP for apt may seem bad, but you should really pay attention to Ubuntu itself: https://github.com/canonical-websites/www.ubuntu.com/issues/... Ubuntu ISOs aren't served securely and are trivially easy to MitM attack. This vulnerability is still being exploited: https://www.bleepingcomputer.com/news/security/turkish-isp-s...

Wow, that's pretty stunning and I'm honestly quite shocked it's still the case in '19. Just downloaded Ubuntu server for some local instances here at home and realized that I hit this path without even knowning. [edit] Looks like ISO signatures are served over HTTP as well.

It seems the last days some people are actively looking for http downloads.

Videolan and apt/get now. Here is why videolan doesn't do it: https://www.beauzee.fr/2017/07/04/videolan-and-https/

TLDR; They can't force HTTPS to 3rd parties, which is why they can't do it. It's not as simple as running LE.

Re: Remote code execution vulnerability in apt/apt-get

#143

Post by [deleted] » Wed, Jan 23, 2019, 12:42 AM UTC

bigiain wrote: post #125

vvanders wrote: post #107

Earlier quoted context omitted.

> and the keys are obtained from trusted sources Isn't that a little hard if the verification keys(from that link) are served over HTTP[1][2]? [1] http://releases.ubuntu.com/18.04/SHA256SUMS.gpg [2] http://releases.ubuntu.com/?_ga=2.21478331.1690774166.154812...

Those are GPG signed SHA hashes. Sure anyone MITMing the http connection could change them, but for them too be valid signatures for the theoretically-modified ISO you've ended up with, they either need the correct GPG private key to generate that new signature, or they need to convince you to accept a bogus public key for ubuntu-archive-keyring.gpg

[deleted]

Re: Remote code execution vulnerability in apt/apt-get

#144

Post by kelnos » Wed, Jan 23, 2019, 12:44 AM UTC

systematical wrote: post #133

So will someone more in the know than myself tell me if using apt-transport-https is a reasonable solution to this problem, or, at least mitigates the problem? As someone who uses Linux as their personal O.S. and administers some at work, but doesn't think in bash, I'd really like an answer :-)

It will mitigate the possibility of someone MitM'ing your connection to the package mirror. It won't protect you against a malicious package mirror.

Re: Remote code execution vulnerability in apt/apt-get

#145

Post by moosingin3space » Wed, Jan 23, 2019, 12:45 AM UTC

systematical wrote: post #133

So will someone more in the know than myself tell me if using apt-transport-https is a reasonable solution to this problem, or, at least mitigates the problem? As someone who uses Linux as their personal O.S. and administers some at work, but doesn't think in bash, I'd really like an answer :-)

It makes it so that your mirror would have to be exploiting apt, instead of effectively anyone. As a result, using TLS for downloads would mitigate this (but not fix it).

I've read the arguments against HTTPS for apt many times. They're wrong.

Re: Remote code execution vulnerability in apt/apt-get

#146

Post by jolmg » Wed, Jan 23, 2019, 1:00 AM UTC

NicoJuicy wrote: post #142

vvanders wrote: post #80

Earlier quoted context omitted.

Wow, that's pretty stunning and I'm honestly quite shocked it's still the case in '19. Just downloaded Ubuntu server for some local instances here at home and realized that I hit this path without even knowning. [edit] Looks like ISO signatures are served over HTTP as well.

It seems the last days some people are actively looking for http downloads. Videolan and apt/get now. Here is why videolan doesn't do it: https://www.beauzee.fr/2017/07/04/videolan-and-https/ TLDR; They can't force HTTPS to 3rd parties, which is why they can't do it. It's not as simple as running LE.

I imagine that every distribution system that relies on mirrors has a similar setup. It makes a lot of sense.

Re: Remote code execution vulnerability in apt/apt-get

#147

Post by all_blue_chucks » Wed, Jan 23, 2019, 1:23 AM UTC

whydoyoucare wrote: post #136

all_blue_chucks wrote: post #118

Earlier quoted context omitted.

Defense in depth is just an industry term for redundant security. For example, you can mitigate tampering with data transfers by signing the data itself AND ALSO by signing the channel it's transferred over with TLS. If a flaw is found in one of those methods, the other will still protect you. The process of listing all the security failure points and documenting the redundant mechanisms to protect them is called thr…

Yes, this works. In theory. In practice, a simple model is needed that everyone can follow and implement consistently. That, does not exist. Lookup "threat modeling" and you will see how abstract a notion it is (even your comment calls for a "redundant mechanism" that may not be exactly what you are looking for), and how little information is available. End result? Most do it for the "checkbox effect". Don't get me w…

You're right that it's not simple. In fact, studying security-senstivie ways in which software tends to fail and how those failures can be mitigated is an entire field unto itself. Software developers can't be expected to get it right on their own. That's why all major software companies have security engineers on staff.

Open source projects, unfortunately, rarely have such contributors. Probably because building stuff is more fun than threat modeling (which can be quite tedious to do properly).

Re: Remote code execution vulnerability in apt/apt-get

#148

Post by bigiain » Wed, Jan 23, 2019, 1:29 AM UTC

vvanders wrote: post #138

bigiain wrote: post #125

Earlier quoted context omitted.

Those are GPG signed SHA hashes. Sure anyone MITMing the http connection could change them, but for them too be valid signatures for the theoretically-modified ISO you've ended up with, they either need the correct GPG private key to generate that new signature, or they need to convince you to accept a bogus public key for ubuntu-archive-keyring.gpg

Or they could serve all this over HTTPS where that process would happen automatically when you download. As another poster noted the keyserver in that link will work over http so you're still susceptible to a possible downgrade attack. Given how easy it is to get a LE cert these days it's making me question what other security decision Ubuntu is making that I'm not aware of or have the expertise to evaluate.

Heh. I think that "other poster" may also have been me...

With regards to LE certs, I discussed elsewhere here the problems faced by the apt developers that make the obvious "just install a LE cert!" answer not actually workable for them - they rely heavily of volunteer run mirrors and local proxies. I don't know what Ubuntu's ISO download "server" really is underneath, it's possible they've got similar problems, where either they pay for all the bandwidth themselves, or they let people assume that an ssl secured connection to "ubuntu-mirror.usyd.edu.au" or "ubuntu-mirror.evilhacker.ru" is for some reason "safer" than an http connection...

Re: Remote code execution vulnerability in apt/apt-get

#149

Post by lvs » Wed, Jan 23, 2019, 2:48 AM UTC

rabi_penguin wrote: post #5

Hmm, it's almost as if the author of https://whydoesaptnotusehttps.com/ may have overlooked a few things.

They (ubuntu, at least) have always been overtly hostile about this issue, which seems strange. I recall seeing open issues that just devolved into argument for many years on this. I don't get it.

Re: Remote code execution vulnerability in apt/apt-get

#150

Post by gymshoes » Wed, Jan 23, 2019, 4:32 AM UTC

Sephr wrote: post #55

Using HTTP for apt may seem bad, but you should really pay attention to Ubuntu itself: https://github.com/canonical-websites/www.ubuntu.com/issues/... Ubuntu ISOs aren't served securely and are trivially easy to MitM attack. This vulnerability is still being exploited: https://www.bleepingcomputer.com/news/security/turkish-isp-s...

Linux Mint was breached some time ago: https://blog.linuxmint.com/?p=2994