Remote code execution vulnerability in apt/apt-get • Hacker News Board

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

#11

Post by jwilk » Tue, Jan 22, 2019, 4:21 PM UTC

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

How many of these would result in RCE?

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

#12

Post by dijit » Tue, Jan 22, 2019, 4:23 PM UTC

jwilk wrote: post #11

moviuro wrote: 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&...

How many of these would result in RCE?

64?

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

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

#13

Post by detaro » Tue, Jan 22, 2019, 4:27 PM UTC

dijit wrote: post #12

jwilk wrote: post #11

Earlier quoted context omitted.

How many of these would result in RCE?

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.

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

#14

Post by kerng » Tue, Jan 22, 2019, 4:34 PM UTC

rabi_penguin wrote: post #5

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

Makes me chuckle, since my comment on the HN post yesterday that highlighted that someone will be bitten if security principles are ignored got downvoted.

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

#15

Post by kpcyrd » Tue, Jan 22, 2019, 4:49 PM UTC

It seems debian testing and unstable are still vulnerable:

https://security-tracker.debian.org/tracker/CVE-2019-3462

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

#16

Post by dreta » Tue, Jan 22, 2019, 4:51 PM UTC

feikname wrote: post #8

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

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

#17

Post by spuz » Tue, Jan 22, 2019, 4:52 PM UTC

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?

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

#18

Post by AndyKelley » Tue, Jan 22, 2019, 4:53 PM UTC

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.

HTTP is the null hypothesis, since it's simpler. Usually there is a great reason to reject this null hypothesis - it prevents security vulnerabilities. But if there is no added value, then there is no reason to do it.

Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?

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

#19

Post by LoSboccacc » Tue, Jan 22, 2019, 4:54 PM UTC

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.

also, the apt way to fix this would be to a) move release.gpg out of the package path and b) require the release.gpg to be wrapped and signed with the previous valid key instead of being accepted blindly

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

#20

Post by dijit » Tue, Jan 22, 2019, 4:57 PM UTC

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.

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