Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote code execution vulnerability in apt/apt-get

justi.cz

Post reply on HN
Print view View original

131–140 of 166 posts

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

#131

Post by cordonbleu »

bigiain wrote: post #126
whydoyoucare wrote: post #121

Earlier quoted context omitted.

The Ubuntu verification tutorial (see my previous post) points to keyserver.ubuntu.com.

Hmmm, I just had a look there. keyserver.ubuntu.com is available over http as well as https, which means it's probably susceptible to a downgrade attack if you're mitming it - which would let you serve a bogus public key and therefore generate apparently valid signatures for the hash for a modified ISO. That's not good...

its happened in variant form already, this is why habits of complacency should be kept in check.

remember this ? V

https://www.theregister.co.uk/2016/02/21/linux_mint_hacked_m...

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

#132

Post by cryptonector »

trulyrandom wrote: post #62
hannob wrote: post #21

Earlier quoted context omitted.

HTTPS: A malicious mirror operator can pwn you. HTTP: Everyone can pwn you. Not saying the first one is ideal, but the second one is definitely worse.

With HTTP an attacker still has to MITM the connection between you and the mirror operator. So, definitely not "everyone".

That includes: coffee shops, ISPs, employers, everyone who can hack their routers, anyone who can spoof DNS, etc. That might as well be "everyone".

STOP IT. Though shall use HTTPS.

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

#133

Post by systematical »

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

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

#134

Post by tracker1 »

moviuro wrote: post #90
tracker1 wrote: post #88

Earlier quoted context omitted.

And overcoming both is much harder than overcoming either on their own.

In the worst case, you only need to overcome one. And you ~double your attack surface.

Which one? If you gain control of a server, you'd still have to overcome signing... and you only control that single server, not all replicas (for a bug like in TFA).

Could you describe a way to have double the attack surface that would effect the majority of peer servers?

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

#135

Post by deathanatos »

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

APT does not, however, give privacy, which HTTPS/TLS would. (Those in favor argue that TLS doesn't help here, as you can still see that you're connecting to Ubuntu, so it's still obvious that you're downloading updates. I personally disagree w/ this stance: I think there is value in protecting which packages you're pulling updates for, as what packages you have installed can inform someone about what you're doing. I think there's further argument that the sizes of the responses give away which updates you're pulling, but IDK, that seems harder to piece together, and TLS at least raises the bar for that sort of thing.)

The bug discussed in the article circumvents the signature checking, by lying to the parent process about the validity of the signature by being able to essentially execute a sort of XSS/injection attack.

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

#136

Post by whydoyoucare »

all_blue_chucks wrote: post #118
whydoyoucare wrote: post #103

Earlier quoted context omitted.

I believe several terms here need a context, without which they are meaningless. For example, what is an acceptable security model to download and install an OS, how do you exactly define "defense in depth" for the act of downloading and installing an OS, etc.. That will help us define what controls should be in place for the overall OS-download-and-install experience to be secure.

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 wrong, I am not trying to obliterate what you said, just putting some factual data around it.

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

#138

Post by vvanders »

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

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.

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

#139

Post by ru999gol »

kerng wrote: post #14
rabi_penguin wrote: post #5

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

Makes me chuckle, since my comment on the HN post yesterday that highlighted that someone will be bitten if security principles are ignored got downvoted.

I was laughing as well, software people (the HN and open source community in particular) are so stupidly opinionated sometimes, it makes me just cringe whenever its impossible to ignore their dribble.

There really is no excuse not to use HTTPS in 2019, period.

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

#140

Post by nneonneo »

moviuro wrote: post #95
nneonneo wrote: post #54

Earlier quoted context omitted.

Oh for god’s sake will you stop spreading nonsense FUD about https? https is not “broken”. The majority of websites run on https now; most system update mechanisms with the VERY notable exception of apt use https to serve updates. Sure, there are bugs in libraries, but seeing as https is already widespread you’re not exposing yourself to MORE risk by using https over plain http, and you mitigate attacks like this pos…

> The majority of websites run on https now We are talking about a specific use case of https: software repositories, which are far higher-value targets than your random website, with another set of challenges. Your package manager can actually do some things as root; once it's owned, your system is Game Over . Adding yet another lib on top of the (?) most important piece of software on your computer is not a risk to…

If you're that paranoid about OpenSSL, then just sandbox it. Throw the entire `apt-transport-https` subprocess in an unprivileged context. Done.
Post reply on HN