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

101–110 of 166 posts

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

#101

Post by whydoyoucare »

blub wrote: post #98
vvanders wrote: post #80

Earlier quoted context omitted.

Wow, that's pretty stunning and I'm honestly quite shocked it's still the case in '19. Just downloaded Ubuntu server for some local instances here at home and realized that I hit this path without even knowning. [edit] Looks like ISO signatures are served over HTTP as well.

It's one of my pet peeves and I can say that a ton of organisations do this in 2019, including ones that should know better, like Ubuntu. The only secure way to install is to somehow get their key, already have gpg installed and then verify that way.

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

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

#102

Post by whydoyoucare »

dessant wrote: post #97
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...

I usually download it from the kernel.org mirror for this reason. https://mirrors.kernel.org/ubuntu-releases/18.10/

How do you know they obtain it from a trusted source? ;-)

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

#103

Post by whydoyoucare »

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

I believe several terms here need a context, without which they are meaningless. For example, what is an acceptable security model to download and install an OS, how do you exactly define "defense in depth" for the act of downloading and installing an OS, etc.. That will help us define what controls should be in place for the overall OS-download-and-install experience to be secure.

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

#104

Post by whydoyoucare »

nneonneo wrote: post #54
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…

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 pos…

CA-model requires "extra" investment, that not many are willing to make. Plus there is a secure way to distribute an OS, which does not require https [download over http, obtain signed check-sums from a trusted source, verify, and proceed with installation].

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

#105

Post by dessant »

whydoyoucare wrote: post #102
dessant wrote: post #97

Earlier quoted context omitted.

I usually download it from the kernel.org mirror for this reason. https://mirrors.kernel.org/ubuntu-releases/18.10/

How do you know they obtain it from a trusted source? ;-)

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

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

#106

Post by nisa »

FWIW you can have https today just install apt-transport-https and use this sources.list:

    deb https://deb.debian.org/debian stable main contrib non-free
    deb https://deb.debian.org/debian-security stable/updates main contrib non-free
    deb https://deb.debian.org/debian stretch-backports main contrib non-free

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

#107

Post by vvanders »

whydoyoucare wrote: post #101
blub wrote: post #98

Earlier quoted context omitted.

It's one of my pet peeves and I can say that a ton of organisations do this in 2019, including ones that should know better, like Ubuntu. The only secure way to install is to somehow get their key, already have gpg installed and then verify that way.

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…

> and the keys are obtained from trusted sources

Isn't that a little hard if the verification keys(from that link) are served over HTTP[1][2]?

[1] http://releases.ubuntu.com/18.04/SHA256SUMS.gpg

[2] http://releases.ubuntu.com/?_ga=2.21478331.1690774166.154812...

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

#109

Post by justicz »

peterwwillis wrote: post #100
thriqon wrote: post #86

Earlier quoted context omitted.

Usually, the packages themselves are not signed with GPG, only the Release file is (containing the hashes of all .deb files). This is actually the default of both Debian and Ubuntu. I never quite understood the reasons behind it... I'd not expect this vuln to happen, though. More info: https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-v...

I kind of get why they did it that way (my guess: managing lots of dev keys was problematic, so they used one key to sign a list of "official-seeming" files). But then why wasn't the Release file's contents verified (assuming this doesn't involve generating collisions for those packages)? "The parent process will trust the hashes returned in the injected 201 URI Done response, and compare them with the values from th…

The hash is done locally in the http worker process. I think you may be confusing headers in the HTTP response with headers in the internal protocol used to communicate with the worker process. The 201 response is not an HTTP response.

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

#110

Post by yjftsjthsd-h »

whydoyoucare wrote: post #101
blub wrote: post #98

Earlier quoted context omitted.

It's one of my pet peeves and I can say that a ton of organisations do this in 2019, including ones that should know better, like Ubuntu. The only secure way to install is to somehow get their key, already have gpg installed and then verify that way.

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…

> As long as verification happens independently, and the keys are obtained from trusted sources, there is nothing wrong in downloading Ubuntu over http.

In the abstract, this is true. In practice, however, the checksums are always downloaded from the same page as the OS and usually over the same (unencrypted) connection from the same servers.

Post reply on HN