So... Debian users will need to grab security fixes for `apt-get` using... `apt-get`?
1) Find list of applicable binary packages, for example by taking a look at https://packages.debian.org/source/wheezy/apt
2) Download http://security.debian.org/dists/wheezy/updates/InRelease, and verify the gpg signature against the archive signing key, found in /etc/apt/trusted.gpg alt. in /etc/apt/trusted.gpg.d/*.gpg
3) Download http://security.debian.org/dists/wheezy/updates/main/binary-..., and verify that its sha256 sum matches what you have in your previously downloaded InRelease file.
4 Inside the downloaded Packages.bz2 you'll find the relative paths as well as the sha256 sums of the packages you want to download.
If nothing else this is a good exercise to see how the different pieces fit together.
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.
That being said, you can try verifying the sha256 and you might catch "them" that way if they didn't think of that.
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 ;)
Original trust is a problem with no possible solution inside a computer.
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.)
Interestingly both are given "urgency=low" ratings; at least 3 other updates have been medium urgency this year.
Edit: sorry should have said on Ubuntu; I've got libapt-inst1.5:amd64 (1.0.1ubuntu2.3) from trusty/main.
But it seems like the CVEs are unavailable, I'm getting 502 Proxy Errors.
It seems like four separate attack vectors are addressed in this update. This all is kind of surprising.
Anybody know how to find better descriptions of these bugs, or the patches that fixed them?
(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.)
http://www.ubuntu.com/usn/usn-2348-1/
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)
Edit:
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.)
In the end I decided to close my eyes and hope for the best.