> does not properly invalidate unauthenticated data (CVE-2014-0488), performs incorrect verification of 304 replies (CVE-2014-0487), does not perform the checksum check when the Acquire::GzipIndexes option is used (CVE-2014-0489) and does not properly perform validation for binary packages downloaded by the apt-get download command (CVE-2014-0490).
There are four specific scenarios that are vulnerable, and none of them appears to be the common scenario of updating packages. Details still sparse, but this seems like a minor security update.
If you know how to verify the signatures properly, that would work. I'm thinking if you don't know that, and if you're willing to do what you just described, you probably don't really care about these CVEs anyway.
sha256 doesn't provide any web-of-trust; if your download is compromised, the sha-sums that you download to verify them could also be compromised in the same way. If the crypto signatures are verified and your installed keyring is genuine (came from a genuine installation media), then you know that the packages you installed (and their signatures) actually came from the Debian project.
That being said, you can try verifying the sha256 and you might catch "them" that way if they didn't think of that.
Well I got the sha256 from the debian site, which is HTTPS secured, which I assume is uncompromised because of this vulnerability, correct? Or am I missing something here?
Yeah that makes sense to me. If you trust ssl. I usually assume that if some three-letter agency wants to hack my computers they are going to find a way and recent history has shown that SSL can be vulnerable too.
I think it's true that without certificate pinning (which you sound like you know about) the various government agencies may easily have people inside your certificate stores that can issue bogus certs. That we've never read of one of these attacks succeeding is further evidence that the conspiracy is working ;)
You can check the package signatures for the downloaded debs in /var/cache/apt/archives by following the links for your architecture at the bottom of https://packages.debian.org/wheezy/apt
(You might need to check the rest of the apt-related debs as well. Just replace apt in the URL with the relevant package name and follow the links at the bottom to get the package hashes. If you're tracking sid instead of wheezy then just replace the distribution name in the URL.)
Yeah, I'm having a hard time finding details on the vulnerabilities. A lot of the links in the advisories are broken, and the descriptions on the Mitre CVE pages seem to be awaiting update.
Anybody know how to find better descriptions of these bugs, or the patches that fixed them?
I'm having trouble thinking of a realistic exploit for the first. The second would seem to require not using signing keys which most people have been using for a long time AND the people that are using signing keys (almost everyone) not complaining about bad stuff being substituted in AND the mirror/repo ops not noticing. The third isn't enabled by default and probably doesn't apply to many people. The fourth only applies to people who download and build from source which other than researchers and devs is pretty much no one and is another one of those that relies on everybody not paying attention.
(edited to emphasize that the above isn't some kind of formal pronouncement of The Truth, but it is the logic I used when deciding how to prioritize this situation, which ended up with a conclusion of "not very important, not at all". Your situation not being identical to mine will almost certainly result in a somewhat different conclusion, much as my conclusion would be different if I were in your situation instead of mine.)
It was discovered that APT did not re-verify downloaded files when the
If-Modified-Since wasn't met. (CVE-2014-0487)
It was discovered that APT did not invalidate repository data when it
switched from an unauthenticated to an authenticated state. (CVE-2014-0488)
It was discovered that the APT Acquire::GzipIndexes option caused APT to
skip checksum validation. This issue only applied to Ubuntu 12.04 LTS and
Ubuntu 14.04 LTS, and was not enabled by default. (CVE-2014-0489)
It was discovered that APT did not correctly validate signatures when
downloading source packages using the download command. This issue only
applied to Ubuntu 12.04 LTS and Ubuntu 14.04 LTS. (CVE-2014-0490)
Regarding #1(If-Modified-Since), the vulnerability is that if a hash in the Release file changes, but the file being referred to by the Release file gets served with a 304 response, apt will ignore the updated file and continue to use the old version of the file. even though the old version of the file doesn't match the new hash. An attacker could exploit this to prevent a system from receiving updates, though thankfully it doesn't seem to be possible to exploit this to cause apt to trust an arbitrary package.
Original incorrect speculation below:
Regarding #1 (If-Modified-Since), I'm wondering if perhaps their HTTP client incorrectly accepts a response body with a 304 response (contrary to the HTTP spec)? In that case a malicious server could deliver a file that's blindly trusted as long as it has a status of 304. (This is pure speculation, but I can't think of any other reason this would be a big deal.)
How do you download source packages using the 'download' command? The debian advisory and manpage says that 'download' gives you the binary package, there's another 'apt-get source' command for the source package...
The Ubuntu advisory says "source packages" for some reason. I think it's a typo but it doesn't change the analysis - most people don't use 'apt-get download' to install packages.
