[thriqon]

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

[peterwwillis]

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 the signed package manifest. Since the attacker controls the reported hashes, they can use this vulnerability to convincingly forge any package."

Wtf? This sounds like Apt is just downloading a gpg file and checking if it matches a hash in an HTTP header, and if it does, it just uses whatever is specified, regardless of whether your system already had the right key imported? This makes no sense. Any mirror could return whatever headers it wanted.

This is the real vuln, not header injection. If Apt isn't verifying packages against the keys I had before I started running Apt, there was never any security to begin with. An attacker on a mirror could just provide their own gpg key and Releases file and install arbitrary evil packages.

Can somebody who knows C++ please verify that their fixes actually stop installing packages if the GPG key wasn't already imported into the system? https://github.com/Debian/apt/commit/690bc2923814b3620ace1ff...

[justicz]

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.