It seems debian testing and unstable are still vulnerable: https://security-tracker.debian.org/tracker/CVE-2019-3462
Fixed apt has been just uploaded to unstable:
https://packages.qa.debian.org/a/apt/news/20190122T190408Z.h...
Remote code execution vulnerability in apt/apt-get
81–90 of 166 posts
Re: Remote code execution vulnerability in apt/apt-get
#82Earlier 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".
the moment we are talking about monitoring user's software base, we are practically already talking attackers at the skill level of nation states, so yeah "everyone" in the subset of plausible attackers.
Re: Remote code execution vulnerability in apt/apt-get
#83Earlier 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.
so if north korea is subjugating some poor souls over there, the whole world must suffer along? there could be a setting with a big warning to disable the default HTTPS behaviour...
Re: Remote code execution vulnerability in apt/apt-get
#84Incidentally binaries from support.apple.com are also served on http.
Re: Remote code execution vulnerability in apt/apt-get
#85Hmm, it's almost as if the author of https://whydoesaptnotusehttps.com/ may have overlooked a few things.
I was just coming here to post that
Re: Remote code execution vulnerability in apt/apt-get
#86Am I crazy, or is the bigger problem here not the fact that Apt will just install whatever random package the server provides, whether your system trusts its GPG key or not? What the hell is the point of the keys if the packages are installed anyway??
Usually, the packages themselves are not signed with GPG, only the Release file is (containing the hashes of all .deb files). This is actually the default of both Debian and Ubuntu. I never quite understood the reasons behind it... I'd not expect this vuln to happen, though.
More info: https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-v...
Re: Remote code execution vulnerability in apt/apt-get
#87Earlier quoted context omitted.
The official torrent links are also distributed over insecure HTTP and are also trivially easy to MitM attack.
Ugh couldn’t they just put magnet links on their nice HTTPS site? It sounds like they just really don’t want to have to update their site when new releases come out.
Per the current image / torrent: magnet:?xt=urn:btih:a4104a9d2f5615601c429fe8bab8177c47c05c84&dn=ubuntu-18.04.1.0-live-server-amd64.iso
Re: Remote code execution vulnerability in apt/apt-get
#88Earlier quoted context omitted.
Defense in depth is a thing. SSL provides some security guarantees. Using signed package databases also provide some security guarantees. Both may overlap in what security they provide. BUT! If one fails, the other can continue to provide a subset of the previously available guarantees.
Not in the case of OpenSSL, no. (Some) OpenSSL issues, just as (some) apt issues, end with RCE. Game over. Priv-sep, correctly handling untrusted files (e.g. 1. check signature, then 2. execute whatever; not the other way round), memory-safe languages, etc. would be more welcome additions.
And overcoming both is much harder than overcoming either on their own.
Re: Remote code execution vulnerability in apt/apt-get
#89Hmm, it's almost as if the author of https://whydoesaptnotusehttps.com/ may have overlooked a few things.
I will never understand why people are so proud to have gotten rid of "needless" security. It always ends the same way...
Re: Remote code execution vulnerability in apt/apt-get
#90Earlier quoted context omitted.
Not in the case of OpenSSL, no. (Some) OpenSSL issues, just as (some) apt issues, end with RCE. Game over. Priv-sep, correctly handling untrusted files (e.g. 1. check signature, then 2. execute whatever; not the other way round), memory-safe languages, etc. would be more welcome additions.
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.