Hacker News Reader

Comment by tokenizerrr | Hacker News Reader

Is there any evidence of this having been used in the wild anywhere? If I understand correctly it could have been exploited by people running http apt repositories, or those intercepting the connection?

It seems all my default repositories are http, and not https as I had initially assumed, so this seems pretty bad.

View on HN

https://wiki.debian.org/SecureApt

Upshot is, apt doesn't need to be served over https because when it fetches Release, it also fetches Release.gpg and verifies the signature contained therein. If it can't fetch or the sig doesn't verify, it squawks.

I was going to say: "but if you get MITMed, the attacker can replace the Release.gpg as well", but clearly I didn't understand GPG signage: an attacker won't have Debian's private keys and so won't be able to produce valid signatures.

Spelling out my derp in case someone else had the same thought.

Also, if apt did use HTTPS, it would make client-side vulnerabilities like this one even more likely, since you'd have an entire TLS implementation to contend with. (Though there is certainly some value in using HTTPS to hide what packages you're downloading.)

That is how it works, unless there's a buffer overflow that allows installing undetected corrupted packages. One of things that is surprising about apt-get and its integrity of debian/ubuntu, is nothing requiring root permissions should ever connect to the 'net, let alone download and execute!

> Is there any evidence of this having been used in the wild anywhere?

No.

Reply on news.ycombinator.com