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

121–130 of 166 posts

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

#121

Post by whydoyoucare »

vvanders wrote: post #107
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…

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

The Ubuntu verification tutorial (see my previous post) points to keyserver.ubuntu.com.

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

#122

Post by explainplease » 

    $ sudo sed -i 's/http:/https:/g' /etc/apt/sources.list
    $ sudo apt-get update
    ...
    Err https://us.archive.ubuntu.com trusty/main Sources                          
    Failed to connect to us.archive.ubuntu.com port 443: Connection refused
    ...
    Err https://security.ubuntu.com trusty-security/main amd64 Packages
    Failed to connect to security.ubuntu.com port 443: Connection refused
???

    $ curl -v https://security.ubuntu.com/ubuntu/
    * Hostname was NOT found in DNS cache
    *   Trying 91.189.88.149...
    * connect to 91.189.88.149 port 443 failed: Connection refused
    *   Trying 91.189.88.152...
    * connect to 91.189.88.152 port 443 failed: Connection refused
    *   Trying 91.189.88.161...
    * connect to 91.189.88.161 port 443 failed: Connection refused
    *   Trying 91.189.88.162...
    * connect to 91.189.88.162 port 443 failed: Connection refused
    *   Trying 91.189.91.23...
    * connect to 91.189.91.23 port 443 failed: Connection refused
    *   Trying 91.189.91.26...
    * connect to 91.189.91.26 port 443 failed: Connection refused
    * Failed to connect to security.ubuntu.com port 443: Connection refused
    * Closing connection 0
    curl: (7) Failed to connect to security.ubuntu.com port 443: Connection refused
So even security.ubuntu.com is unavailable over HTTPS? Am I missing something?

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

#123

Post by pfg »

aasasd wrote: post #96

I'm just wondering if the author should've given people more time to pull the updated apt, before publishing the issue. This is only a few days old, right? I'm not familiar with established procedures in such cases, and am curious about the rationale for omitting a time window for the update.

Public disclosure once patches are available is a fairly common policy. Google's Project Zero operates like that as well.

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

#124

Post by bigiain »

vvanders wrote: post #80
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...

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.

> Looks like ISO signatures are served over HTTP as well.

That's less of a problem than it sounds.

Sure you can MITM and change the sig on the fly, but without the private key you cannot generate a valid sig for a modified IOS. (And if Ubuntu have had that private key stolen, there are much much deeper problems than the ISOs being served over http...)

On the other hand, I suspect it's probably fewer than single digit percentages of people who download the ISOs who then jump through the GPG hoops to check the signature is valid. And as with all PGP/GPG keys, you've got the bootstrapping problem of how do you know that your copy of ubuntu-archive-keyring.gpg is real to start with... (I've been to key signing parties, but not in the last ~30 years...)

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

#125

Post by bigiain »

vvanders wrote: post #107
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…

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

Those are GPG signed SHA hashes. Sure anyone MITMing the http connection could change them, but for them too be valid signatures for the theoretically-modified ISO you've ended up with, they either need the correct GPG private key to generate that new signature, or they need to convince you to accept a bogus public key for ubuntu-archive-keyring.gpg

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

#126

Post by bigiain »

whydoyoucare wrote: post #121
vvanders wrote: post #107

Earlier quoted context omitted.

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

The Ubuntu verification tutorial (see my previous post) points to keyserver.ubuntu.com.

Hmmm, I just had a look there.

keyserver.ubuntu.com is available over http as well as https, which means it's probably susceptible to a downgrade attack if you're mitming it - which would let you serve a bogus public key and therefore generate apparently valid signatures for the hash for a modified ISO.

That's not good...

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

#127

Post by cryptonector »

bigiain wrote: post #124
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.

> Looks like ISO signatures are served over HTTP as well. That's less of a problem than it sounds. Sure you can MITM and change the sig on the fly, but without the private key you cannot generate a valid sig for a modified IOS. (And if Ubuntu have had that private key stolen, there are much much deeper problems than the ISOs being served over http...) On the other hand, I suspect it's probably fewer than single digit…

But you need a trust path. If this is the first time you've heard of the Ubuntu signing keys and you have no trust path from them to a signer you trust, then you have a problem, so, yes, all of this should be served over HTTPS. The WebPKI is hardly great, but it's a lot better than nothing.

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

#128

Post by bigiain »

yjftsjthsd-h wrote: post #110
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…

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

Yeah, but the checksums are GPG signed, so you can't change the ISO and then create a valid signature for the new checksum without also having the GPG private key matching the public key you use to check the signature.

Having said that, it seems keyserver.ubuntu.com is happy enough to allow connections via http instead of https, so there's a valid avenue to serve up a bogus public key...

That's a much smaller window of opportunity since if you're already a Ubuntu user you'll have a pre-existing copy of ubuntu-archive-keyring.gpg already, rather than trying to download a possibly mitm-ed public key at the same time as you download the ISO. But I must admit I boggled a little bit when I saw that keyserver.ubuntu.com happily server their public key over http instead of just https...

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

#129

Post by cryptonector »

whydoyoucare wrote: post #104
nneonneo wrote: post #54

Earlier quoted context omitted.

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

Letsencrypt.org.

Stop it, just stop it.

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

#130

Post by bigiain »

dessant wrote: post #105
whydoyoucare wrote: post #102

Earlier quoted context omitted.

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.

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