Hmm, it's almost as if the author of https://whydoesaptnotusehttps.com/ may have overlooked a few things.
You know that HTTPS has the Location header too, right? This attack works just as well against HTTPS clients.
Remote code execution vulnerability in apt/apt-get
61–70 of 166 posts
Re: Remote code execution vulnerability in apt/apt-get
#62Earlier 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?
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".
Re: Remote code execution vulnerability in apt/apt-get
#63Earlier 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&...
APT already supports HTTPS. Enforcing it by default wouldn't increase APT's attack surface significantly.
It would decrease the number/quantity/capacity of available mirrors. I don't know if that quantity would be significant.
Re: Remote code execution vulnerability in apt/apt-get
#64Earlier quoted context omitted.
I think the point is that adding https over http for the current system would always improve security. At it's most broken, https is at least as secure as http and therefore wouldn't reduce the security of the overall system. It adds one more hurdle for an attacker to clear. Similarly, the apt team ignoring a bug like this "because it's protected by https anyway." Is an invalid argument.
> adding https over http for the current system would always improve security No. If an attacker can inject packets that break your SSL lib, but wouldn't have broken your package manager, you added a vuln. Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545
Fair. There are specific library attacks that could result in RCE. However that is also true against curl, ssh, and for that matter could be introduced into your http library at some point. The question then becomes what library do you trust most? OpenSSL is attacked and tested constantly. Things have been found (in your example in 2003!). They have been fixed. Apt can choose to stand on it's shoulders, or go through the entire process themselves by putting together a patchwork of their own solutions that will no doubt get less testing by whitehats and be a juicy target for blackhats.
Re: Remote code execution vulnerability in apt/apt-get
#65Earlier quoted context omitted.
The situation you described is the same thing that happens with a MITM attack with HTTPS. You would get a failed download from any mirror. Do you have a response to my question? "Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?"
Because that just makes things slower for no good reason?
Sounds like an argument for rejecting HTTP+TLS single-wrap too. (For apt — not in general.)
Re: Remote code execution vulnerability in apt/apt-get
#66Using 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...
use torrents
The official torrent links are also distributed over insecure HTTP and are also trivially easy to MitM attack.
Re: Remote code execution vulnerability in apt/apt-get
#67Seems like the discovery of this vuln was a direct result of yesterday's discussion about HTTPS on apt here on HN ( https://news.ycombinator.com/item?id=18958679 ).
No. That would mean less then a day heads-up from the researcher.
It would be a really impressive turn around on the fix from Debian, though ;-).
Re: Remote code execution vulnerability in apt/apt-get
#68Earlier quoted context omitted.
Yet it’s actually not simpler for the user, since their transfer can then be tampered with either by accident or intentionally leaving the user with a broken download and then what do they do? A redownlaod from a different mirror makes no difference.
The situation you described is the same thing that happens with a MITM attack with HTTPS. You would get a failed download from any mirror. Do you have a response to my question? "Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?"
It’s not the same, Comcast and other ISPs don’t tamper with HTTPS, and if they break the HTTPS connection then it’s a clearer problem for the ISP to troubleshoot than corruption.
Sorry I don’t understand what double wrapping has to do with it, or why you’d ever do that.
Re: Remote code execution vulnerability in apt/apt-get
#69I was expect a buffer overflow but this is a quoting issue which is equally applicable to all languages. Are the any language-level methods which make such bugs impossible (or much harder)? Heavy-weight strongly-typed HTTP libraries can force you to always construct headers in a way that handles quoting for you but people seem to love "light" solutions.
Using a binary protocol library for RPC (e.g. gRPC, raw protobufs, etc.) rather than writing your own text-based protocol incorrectly.
Re: Remote code execution vulnerability in apt/apt-get
#70Earlier quoted context omitted.
APT already supports HTTPS. Enforcing it by default wouldn't increase APT's attack surface significantly.
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.