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

51–60 of 166 posts

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

#51

Post by AndyKelley »

jamp897 wrote: post #41
AndyKelley wrote: post #18

Earlier quoted context omitted.

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?

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?"

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

#52

Post by [deleted] »

moviuro wrote: post #46
skywhopper wrote: post #39

Earlier quoted context omitted.

So your argument is that bugs in OpenSSL (a necessarily very complex piece of software) mean that using SSL to increase network security is a bad thing?

No. My argument is that both arguments do exist and security is all about middle-ground. Do we add (yet another) layer of (bug-riddled) software to defeat one possible sort of exploits, or not? How much does it cost? (Time, money, etc.) Other options include: not handle http directly in the package manager but use a known-good library (curl?); do priv-sep; not having the package manager execute code from a file befor…

[deleted]

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

#53

Post by jmvoodoo »

moviuro wrote: post #46
skywhopper wrote: post #39

Earlier quoted context omitted.

So your argument is that bugs in OpenSSL (a necessarily very complex piece of software) mean that using SSL to increase network security is a bad thing?

No. My argument is that both arguments do exist and security is all about middle-ground. Do we add (yet another) layer of (bug-riddled) software to defeat one possible sort of exploits, or not? How much does it cost? (Time, money, etc.) Other options include: not handle http directly in the package manager but use a known-good library (curl?); do priv-sep; not having the package manager execute code from a file befor…

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.

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

#54

Post by nneonneo »

moviuro wrote: post #46
skywhopper wrote: post #39

Earlier quoted context omitted.

So your argument is that bugs in OpenSSL (a necessarily very complex piece of software) mean that using SSL to increase network security is a bad thing?

No. My argument is that both arguments do exist and security is all about middle-ground. Do we add (yet another) layer of (bug-riddled) software to defeat one possible sort of exploits, or not? How much does it cost? (Time, money, etc.) Other options include: not handle http directly in the package manager but use a known-good library (curl?); do priv-sep; not having the package manager execute code from a file befor…

Oh for god’s sake will you stop spreading nonsense FUD about https? https is not “broken”. The majority of websites run on https now; most system update mechanisms with the VERY notable exception of apt use https to serve updates.

Sure, there are bugs in libraries, but seeing as https is already widespread you’re not exposing yourself to MORE risk by using https over plain http, and you mitigate attacks like this post. Any random coffee shop, untrusted public WiFi, or attacker with a Pineapple could have used this attack to MITM HTTP apt, whereas the attacker would have to compromise an upstream mirror to pull off the same attack over HTTPS.

And re: the CA model, if you’re THAT worried about compromised or fake certs, then pin the cert for a root server like debian.org, then download PGP-signed cert bundles for mirrors and enforce certificate pinning using those bundles only. Done. Apple and Microsoft use cert pinning for their update systems (IIRC).

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

#55

Post by Sephr »

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

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

#56

Post by nneonneo »

AndyKelley wrote: post #51
jamp897 wrote: post #41

Earlier 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?"

Because that just makes things slower for no good reason?

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

#57

Post by moviuro »

jmvoodoo wrote: post #53
moviuro wrote: post #46

Earlier quoted context omitted.

No. My argument is that both arguments do exist and security is all about middle-ground. Do we add (yet another) layer of (bug-riddled) software to defeat one possible sort of exploits, or not? How much does it cost? (Time, money, etc.) Other options include: not handle http directly in the package manager but use a known-good library (curl?); do priv-sep; not having the package manager execute code from a file befor…

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

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

#58

Post by Ajedi32 »

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

APT already supports HTTPS. Enforcing it by default wouldn't increase APT's attack surface significantly.

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

#59

Post by nyolfen »

Sephr wrote: post #55

Using 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
Post reply on HN