Re:Remote code execution vulnerability in apt/apt-get
by raesene9 on Tuesday January 22, 2019 @12:05PM
(#18969856)
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
by gnulinux on Tuesday January 22, 2019 @04:25PM
(#18972641)
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
by hannob on Tuesday January 22, 2019 @11:57AM
(#18969735)
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.
Re:Remote code execution vulnerability in apt/apt-get
by trulyrandom on Tuesday January 22, 2019 @01:25PM
(#18970784)
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
by cryptonector on Tuesday January 22, 2019 @06:01PM
(#18973550)
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
by trulyrandom on Wednesday January 23, 2019 @02:44PM
(#18981952)
Fair enough. I agree that HTTPS is valuable here. I was just being overly pedantic, my bad.
Re:Remote code execution vulnerability in apt/apt-get
by DoctorOetker on Tuesday January 22, 2019 @02:17PM
(#18971378)
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
by detaro on Tuesday January 22, 2019 @11:58AM
(#18969753)
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.
Re:Remote code execution vulnerability in apt/apt-get
by gnulinux on Tuesday January 22, 2019 @04:26PM
(#18972655)
With HTTPS a MitM attacker can still refuse to serve a specific package.
Re:Remote code execution vulnerability in apt/apt-get
by shinigami on Tuesday January 22, 2019 @12:00PM
(#18969779)
https prevents an attacker which can compromise the network. It does not prevent an attacker who can compromise the mirror. The author can't compromise an existing mirror, so they wouldn't able to exploit it (through the network) if the servers were using https.
> 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?