3 ms·
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 repositor
by tokenizerrr 12y ago
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.
- DrewHintz 12y ago> Is there any evidence of this having been used in the wild anywhere? No.
- philsnow 12y agohttps://wiki.debian.org/SecureApt 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.
- AceJohnny2 12y agoI 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.
- agwa 12y agoAlso, 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.)
- disjointrevelry 12y agoThat 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!