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

111–120 of 166 posts

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

#111

Post by yjftsjthsd-h »

AndyKelley wrote: post #18
jamp897 wrote: post #6

Earlier quoted context omitted.

He never explains why he wants to use HTTP, it’s only about why he thinks HTTPS isn’t nesscary.

HTTP is the null hypothesis, since it's simpler. Usually there is a great reason to reject this null hypothesis - it prevents security vulnerabilities. But if there is no added value, then there is no reason to do it. Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?

> Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?

If it's the exact same implementation then that doesn't really add a second layer. If, however, I am provided the option to run HTTPS over a VPN tunnel, then I would happily do that in a heartbeat. In fact, I frequently do run my web traffic over a proxy, thereby giving it at least two layers of encryption.

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

#112

Post by wtetzner »

nisa wrote: post #106

FWIW you can have https today just install apt-transport-https and use this sources.list: deb https://deb.debian.org/debian stable main contrib non-free deb https://deb.debian.org/debian-security stable/updates main contrib non-free deb https://deb.debian.org/debian stretch-backports main contrib non-free

Do you have to install apt-transport-https over http?

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

#113

Post by viraptor »

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…

With https libs you're trading one potential issue with another class of issues. Https implementation may have an rce but (this happens extremely infrequently and can be patched quickly). At the same time, it prevents the whole class of issues of MitM, whatever element of the underlying system they would target. (Which potentially need client changes to multiple elements to get fixed) This is a pretty easy decision to make.

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

#114

Post by jamieweb »

perennate wrote: post #78
jamieweb wrote: post #76

All my servers do an update and dist-upgrade every 24 hours, and it emails me the log. I saw this post just a few minutes after checking the log for today. I imagine that this is a higher risk for virtualized servers in a public cloud. I use Linode, so somebody else could have set up a Linode to MITM everybody and serve the exploit. If it were a private home or corporate network, somebody would either have to be on y…

> I imagine that this is a higher risk for virtualized servers in a public cloud. I think it might be the other way around (at least in terms of virtualized servers versus physical servers, both on public cloud) -- it is easier to implement IP address and other filtering measures with virtualized servers than inside physical network switches. Linode and other virtual machine providers almost universally implement thi…

That's a good point actually - although when using dedicated hardware I usually have in my mind that everything is raw rather than abstracted by a hypervisor, so this sort of thing should be more expected.

With a public cloud you don't really know how it's set up on their end, as there are countless different ways to do it.

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

#115

Post by gnulinux »

raesene9 wrote: post #31
spuz wrote: post #17

Earlier quoted context omitted.

I think I understand the exploit but I don't understand whether apt using https would prevent it or not. The author says: > Yes, a malicious mirror could still exploit a bug like this, even with https. and: > I wouldn’t have been able to exploit the Dockerfile at the top of this post if the default package servers had been using https. So which is it?

Essentially adding HTTPS would make the attack harder to exploit. It's not that HTTPS is a pancea (it's not) but that it raises the bar to a successful attack. With HTTP, this can be exploited by anyone who can MITM a connection between you and the APT server or has control of your DNS. If you consider all the cases like wi-fi hotspots, that's (potentially) quite a large set of attackers, and a relatively easy attack…

We're talking about a million dollar software designed for governments and is sold only to highest bidders. I refuse to believe using HTTPS would be helpful here. This attack uses state-of-art to exploit HTTP and there is no reason to assume it wouldn't use state-of-art if it were HTTPS.

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

#116

Post by gnulinux »

detaro wrote: post #24
spuz wrote: post #17

Earlier quoted context omitted.

I think I understand the exploit but I don't understand whether apt using https would prevent it or not. The author says: > Yes, a malicious mirror could still exploit a bug like this, even with https. and: > I wouldn’t have been able to exploit the Dockerfile at the top of this post if the default package servers had been using https. So which is it?

Both. Without HTTPS, you can execute the attack if you can MITM the connection to the package repository. If HTTPS is used, you need to be the package repository to do the attack, or need a certificate to MITM the connection so you can pretend to be it.

With HTTPS a MitM attacker can still refuse to serve a specific package.

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

#117

Post by stouset »

whydoyoucare wrote: post #101
blub wrote: post #98

Earlier quoted context omitted.

It's one of my pet peeves and I can say that a ton of organisations do this in 2019, including ones that should know better, like Ubuntu. The only secure way to install is to somehow get their key, already have gpg installed and then verify that way.

As long as verification happens independently, and the keys are obtained from trusted sources, there is nothing wrong in downloading Ubuntu over http. It appears this to be the case, see "How to verify Ubuntu download" tutorial that provides detailed steps: https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify... (If you plan to install an Operating System, then I believe some homework is in order -- you canno…

> If you plan to install an Operating System, then I believe some homework is in order -- you cannot expect the OS developers to spoon-feed you trivial security aspects that are expected to be a skill-set that you, the operating system installer, or System Administrator, do possess

If you plan to publish an operating system, you should take effort to reduce this homework as much as is humanly possible. For every step where a user is expected to—but not explicitly required to—perform extra work to ensure their own security, the overwhelming majority of users will not take these extra steps.

Arguing that they "should" gets us nowhere.

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

#118

Post by all_blue_chucks »

whydoyoucare wrote: post #103
all_blue_chucks wrote: post #49

Earlier quoted context omitted.

That's because security requires defense in depth. If the failure of a single security control can invalidate your security model, your security model is inadequate. It should require multiple things to go wrong for catastrophic failure. This is a lesson from engineering that hasn't made its way to software development yet (outside of security engineering, anyway).

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

For a system that installs OS-level binaries as root, it would absolutely be appropriate to threat model it and hold it to a defense in depth standard. In defense systems, they often require three levels of defense in depth, the last being an air gap network.

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

#119

Post by joombaga »

Ajedi32 wrote: post #70
loeg wrote: post #63

Earlier quoted context omitted.

It would decrease the number/quantity/capacity of available mirrors. I don't know if that quantity would be significant.

You would lose the ability to do transparent caching which I agree is rather annoying, but I think most environments where that sort of caching occurs (mostly corporate and school networks) also have the means to explicitly configure client machines to use an internal caching mirror.

Those environments tend to MITM https traffic as well. At least the companies I've worked for can.

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

#120

Post by richardwhiuk »

wtetzner wrote: post #112
nisa wrote: post #106

FWIW you can have https today just install apt-transport-https and use this sources.list: deb https://deb.debian.org/debian stable main contrib non-free deb https://deb.debian.org/debian-security stable/updates main contrib non-free deb https://deb.debian.org/debian stretch-backports main contrib non-free

Do you have to install apt-transport-https over http?

No, but it might be a pain not to:

wget https://cdn-aws.deb.debian.org/debian-security/pool/updates/...

dpkg -i apt-transport-https_1.4.9_amd64.deb

apt-transport-https is going away in apt 1.5 anyway

Post reply on HN