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

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

#151

Post by giovannibajo1 » Wed, Jan 23, 2019, 5:03 AM UTC

moviuro wrote: post #57

jmvoodoo wrote: post #53

Earlier quoted context omitted.

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

Even ignoring the fact that there are far better libraries than OpenSSL today (eg: BoringSSL), apt already implements a sandbox-like approach (as the article explains); I'm not sure if the subprocesses are actually sandboxed, but obviously they should and at that point, a vulnerability like the one you cited shouldn't let the attacker escape the very narrow sandbox.

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

#152

Post by dessant » Wed, Jan 23, 2019, 5:35 AM UTC

bigiain wrote: post #130

dessant wrote: post #105

Earlier quoted context omitted.

I assume that they check the signatures using keys that they've exchanged in person by booping noses.

You're happy to just assume someone else checks the .sig? Why don't you do it yourself?

I also do it myself. Boop

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

#153

Post by Kliment » Wed, Jan 23, 2019, 12:13 PM UTC

If this were one of those bugs that do the full PR bullshit run and use a catchy name and a landing page, I'd propose it be called "Inapt"

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

#154

Post by SmellyGeekBoy » Wed, Jan 23, 2019, 12:13 PM UTC

stouset wrote: post #117

whydoyoucare wrote: post #101

Earlier quoted context omitted.

As long as verification happens independently, and the keys are obtained from trusted sources, there is nothing wrong in downloading Ubuntu over http. It appears this to be the case, see "How to verify Ubuntu download" tutorial that provides detailed steps: https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify... (If you plan to install an Operating System, then I believe some homework is in order -- you canno…

> If you plan to install an Operating System, then I believe some homework is in order -- you cannot expect the OS developers to spoon-feed you trivial security aspects that are expected to be a skill-set that you, the operating system installer, or System Administrator, do possess If you plan to publish an operating system, you should take effort to reduce this homework as much as is humanly possible . For every ste…

Indeed, and adding these extra verification steps just feeds the "Linux is too complicated for ordinary people" crowd.

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

#155

Post by opless » Wed, Jan 23, 2019, 12:16 PM UTC

joombaga wrote: post #119

Ajedi32 wrote: post #70

Earlier quoted context omitted.

You would lose the ability to do transparent caching which I agree is rather annoying, but I think most environments where that sort of caching occurs (mostly corporate and school networks) also have the means to explicitly configure client machines to use an internal caching mirror.

Those environments tend to MITM https traffic as well. At least the companies I've worked for can.

Those companies really need to learn what privacy means.

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

#156

Post by opless » Wed, Jan 23, 2019, 12:17 PM UTC

Ajedi32 wrote: post #70

loeg wrote: post #63

Earlier quoted context omitted.

It would decrease the number/quantity/capacity of available mirrors. I don't know if that quantity would be significant.

You would lose the ability to do transparent caching which I agree is rather annoying, but I think most environments where that sort of caching occurs (mostly corporate and school networks) also have the means to explicitly configure client machines to use an internal caching mirror.

You could run a caching mirror for such things, such as artifactory for example.

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

#157

Post by ptx » Wed, Jan 23, 2019, 12:54 PM UTC

aboutruby wrote: post #108

ChrisCinelli wrote: post #84

Incidentally binaries from support.apple.com are also served on http.

The downloads are in an HTTPS page leading to HTTPS download links, and HTTP redirects to HTTPS: https://support.apple.com/downloads/quicktime for instance.

> and HTTP redirects to HTTPS

...or to anywhere a MITM attacker wants to redirect you.

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

#158

Post by justinclift » Wed, Jan 23, 2019, 1:25 PM UTC

all_blue_chucks wrote: post #49

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

> If the failure of a single security control can invalidate your security model, your security model is inadequate.

As an example, when an admin gets an AWS Security Group wrong, thereby exposing database servers / redis / customer data. Consequence... multimillion $ fines, brand/reputation damage.

It's kind of sad how badly things are set up to fail sometimes. :(

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

#159

Post by blattimwind » Wed, Jan 23, 2019, 1:40 PM UTC

all_blue_chucks wrote: post #49

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

One really obvious thing that occurs to me is that apt uses separate processes for network I/O but fails to reduce their privileges.

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

#160

Post by blattimwind » Wed, Jan 23, 2019, 1:42 PM UTC

moviuro wrote: post #48

zaarn wrote: post #47

Earlier quoted context omitted.

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.

> Priv-sep

Apt even has the had part already implemented by separating the network I/O in other processes. Only problem is that those currently write directly to system directories, but that can be fixed.