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

21–30 of 166 posts

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

#21

Post by hannob »

spuz wrote: post #17
rabi_penguin wrote: post #5

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?

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

#22

Post by guest2143 »

jamp897 wrote: post #6
rabi_penguin wrote: post #5

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

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.

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

#23

Post by null_content »

moviuro wrote: post #7
rabi_penguin wrote: post #5

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&...

That, and Debian would fuck up the implementation.

Lest anyone forgets:

https://www.schneier.com/blog/archives/2008/05/random_number...

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

#24

Post by detaro »

spuz wrote: post #17
rabi_penguin wrote: post #5

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?

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

#25

Post by da_chicken »

detaro wrote: post #13
dijit wrote: post #12

Earlier quoted context omitted.

64? https://nvd.nist.gov/vuln/search/results?form_type=Advanced&...

Fulltext search for "rce", which finds "resou_rce_", "sou_rce_", does not give a number of RCE vulnerabilities.

As far as I can tell, NIST doesn't directly directly use the term RCE. CVE-2010-5298 is an OpenSSL vulnerability that allows data injection that could potentially result in code execution, but there's no easy way to see that from NIST's categorization:

https://nvd.nist.gov/vuln/detail/CVE-2010-5298

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

#26

Post by shinigami »

spuz wrote: post #17
rabi_penguin wrote: post #5

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?

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.

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

#27

Post by detaro »

dijit wrote: post #20
detaro wrote: post #13

Earlier quoted context omitted.

Fulltext search for "rce", which finds "resou_rce_", "sou_rce_", does not give a number of RCE vulnerabilities.

Except that "EXACT MATCH" is enabled, try yourself. (It should be noted that it /does/ match on "possible RCE", which buffer overflows are often tagged with.)

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.

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

#28

Post by detaro »

da_chicken wrote: post #25
detaro wrote: post #13

Earlier quoted context omitted.

Fulltext search for "rce", which finds "resou_rce_", "sou_rce_", does not give a number of RCE vulnerabilities.

As far as I can tell, NIST doesn't directly directly use the term RCE. CVE-2010-5298 is an OpenSSL vulnerability that allows data injection that could potentially result in code execution, but there's no easy way to see that from NIST's categorization: https://nvd.nist.gov/vuln/detail/CVE-2010-5298

that's an additional problem with relying on text search.

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

#29

Post by dijit »

detaro wrote: post #27
dijit wrote: post #20

Earlier quoted context omitted.

Except that "EXACT MATCH" is enabled, try yourself. (It should be noted that it /does/ match on "possible RCE", which buffer overflows are often tagged with.)

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. :(

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

#30

Post by _wmd »

rabi_penguin wrote: post #5

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 historically been one of the buggiest pieces of code in existence. Despite this being a game over RCE, it's the first of its kind in many years. If OpenSSL had been in the mix, Apt would have required forced upgrades /far/ more often. https://www.openssl.org/news/vulnerabilities.html

Post reply on HN