Live data from Hacker News

Remote code execution vulnerability in apt/apt-get

justi.cz

31–40 of 166 posts

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

#31
post #17

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

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 to pull off in a lot of cases.

With HTTPS, the attacker has either to compromise the whole APT mirror or has to get a valid HTTPS certificate for an APT mirror. This is likely harder to pull off, especially when you look at the work on improving CA security that the browser vendors have been doing over the last couple of years.

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

#32
post #29
post #27

Earlier quoted context omitted.

I have. Search for "ontgome" and it finds the bugs containing "Montgomery" (I have taken your url and just replaced the search word): https://nvd.nist.gov/vuln/search/results?form_type=Advanced&... I'm not saying none of the results from your search are RCEs, but not all are, and many are fairly speculative.

Argh, that's frustrating, I checked 4 of them and thought it was fine. The problem is that there seem to be many classifications of remote code execution including buffer overflow and "code injection" and you can't choose multiple. :(

Yes, I also was surprised that the search didn't have more useful tools (e.g. search by high ranking in individual factors, or even just sort by severity: confirmed RCEs should all by very high)

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

#34
post #30

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

Every time this site comes up people entirely miss the point in this regard -- Debian operates a large voluntary network of mirrors. You are not trusting content coming from Debian, you're trusting it coming from the mirror. SSL only secures the link between the client and the potentially compromised mirror, it does not solve problems like the one from the article. Meanwhile it's worth pointing out that OpenSSL has h…

I don't think that an argument that using HTTPS actively decreases the security of a connection really holds all that well.

If you don't think OpenSSL is a high enough quality implementation, there are many others to choose from.

Even with a range of mirrors, it would still raise the bar for attackers, to require HTTPS.

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

#35
post #7

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

OTOH, they would have been right if there had been (yet another) bug in openssl/whatever lib would be used for https. FWIW: 16 vulns in apt in NVD [0]; but 202 for openssl [1] [0] https://nvd.nist.gov/vuln/search/results?form_type=Advanced&... [1] https://nvd.nist.gov/vuln/search/results?form_type=Advanced&...

OpenSSL is not the only available implementation of SSL.

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

#36
post #7

Earlier quoted context omitted.

OTOH, they would have been right if there had been (yet another) bug in openssl/whatever lib would be used for https. FWIW: 16 vulns in apt in NVD [0]; but 202 for openssl [1] [0] https://nvd.nist.gov/vuln/search/results?form_type=Advanced&... [1] https://nvd.nist.gov/vuln/search/results?form_type=Advanced&...

OpenSSL is not the only available implementation of SSL.

Realistically, it's the one that's gonna be used in apt though. (E.g. the existing HTTPS transport uses curl, which uses OpenSSL)

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

#37
post #33
post #15

It seems debian testing and unstable are still vulnerable: https://security-tracker.debian.org/tracker/CVE-2019-3462

Yep, this is our daily reminder that they're called "testing" and "unstable" for a reason. They're not meant for production.

New fixes often land in unstable/testing before going to stable branches.

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

#38
post #36

Earlier quoted context omitted.

OpenSSL is not the only available implementation of SSL.

Realistically, it's the one that's gonna be used in apt though. (E.g. the existing HTTPS transport uses curl, which uses OpenSSL)

Sure, my point was more that if it's a serious concern to use OpenSSL (Personally I don't think it is, as a lot of work has been done in recent years to improve that codebase), that other options are available.

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

#39
post #7

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

OTOH, they would have been right if there had been (yet another) bug in openssl/whatever lib would be used for https. FWIW: 16 vulns in apt in NVD [0]; but 202 for openssl [1] [0] https://nvd.nist.gov/vuln/search/results?form_type=Advanced&... [1] https://nvd.nist.gov/vuln/search/results?form_type=Advanced&...

So your argument is that bugs in OpenSSL (a necessarily very complex piece of software) mean that using SSL to increase network security is a bad thing?

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

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

Some country's firewalls distrupt https, which makes downloading things via https difficult.

Which countries? I’ve only seen HTTP connections tampered with in practice, and China’s GFW blocks HTTP no different than HTTPS from what I’ve seen.
Post reply on HN