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

41–50 of 166 posts

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

#41

Post by jamp897 »

AndyKelley wrote: post #18
jamp897 wrote: post #6

Earlier quoted context omitted.

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?

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.

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

#42

Post by jwilk »

detaro wrote: post #36
raesene9 wrote: post #35

Earlier quoted context omitted.

OpenSSL is not the only available implementation of SSL.

Realistically, it's the one that's gonna be used in apt though. (E.g. the existing HTTPS transport uses curl, which uses OpenSSL)

libcurl has many TLS backends. APT before 1.6 actually uses the GnuTLS one.

APT ≥ 1.6 doesn't use libcurl; it uses GnuTLS directly.

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

#43

Post by detaro »

jwilk wrote: post #42
detaro wrote: post #36

Earlier quoted context omitted.

Realistically, it's the one that's gonna be used in apt though. (E.g. the existing HTTPS transport uses curl, which uses OpenSSL)

libcurl has many TLS backends. APT before 1.6 actually uses the GnuTLS one. APT ≥ 1.6 doesn't use libcurl; it uses GnuTLS directly.

I stand corrected, thx.

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

#44

Post by geofft »

skywhopper wrote: post #39
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&...

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, their argument is that bugs in OpenSSL mean that using SSL when it does not actually increase network security is a bad thing. Reduce your attack surface. Use the things you need to use; don't use things you don't need to use.

Whether apt using OpenSSL would in fact increase network security is a separate and debatable question, but the argument as stated assumes it would not, and is sound.

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

#45

Post by kanox »

I was expect a buffer overflow but this is a quoting issue which is equally applicable to all languages. Are the any language-level methods which make such bugs impossible (or much harder)?

Heavy-weight strongly-typed HTTP libraries can force you to always construct headers in a way that handles quoting for you but people seem to love "light" solutions.

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

#46

Post by moviuro »

skywhopper wrote: post #39
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&...

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 before it checked its authenticity...

My personal opinion on the topic is that authenticating servers is a good thing to do (https does this; encryption is an added benefit), but time has shown that https is broken: libs are full of holes; the CA model is broken by design. Maybe share updates using ssh?

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

#47

Post by zaarn »

geofft wrote: post #44
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, their argument is that bugs in OpenSSL mean that using SSL when it does not actually increase network security is a bad thing. Reduce your attack surface. Use the things you need to use; don't use things you don't need to use. Whether apt using OpenSSL would in fact increase network security is a separate and debatable question, but the argument as stated assumes it would not, and is sound.

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.

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

#48

Post by moviuro »

zaarn wrote: post #47
geofft wrote: post #44

Earlier quoted context omitted.

No, their argument is that bugs in OpenSSL mean that using SSL when it does not actually increase network security is a bad thing. Reduce your attack surface. Use the things you need to use; don't use things you don't need to use. Whether apt using OpenSSL would in fact increase network security is a separate and debatable question, but the argument as stated assumes it would not, and is sound.

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.

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

#49

Post by all_blue_chucks »

rabi_penguin wrote: post #5

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

That's because security requires defense in depth. If the failure of a single security control can invalidate your security model, your security model is inadequate.

It should require multiple things to go wrong for catastrophic failure. This is a lesson from engineering that hasn't made its way to software development yet (outside of security engineering, anyway).

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

#50

Post by cwyers »

gtirloni wrote: post #37
ChrisSD wrote: post #33

Earlier quoted context omitted.

Yep, this is our daily reminder that they're called "testing" and "unstable" for a reason. They're not meant for production.

New fixes often land in unstable/testing before going to stable branches.

I would hope so! Why have a testing branch if you're not going to test things in it?
Post reply on HN