This is my personal analysis of the CVEs, read this with a grain of salt.
Preface: signing keys
Most repositories digitally sign their packages and lists using such a key. For the official repos, the keys are installed together with the base system. If you manually add a repository either directly by adding it to your /etc/apt/sources.lst or /etc/apt/sources.list.d, then you need to add that repository's key manually:
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com ID
or apt-key add FILEin case you downloaded the key separately.
I'm not 100% sure, but IMHO when using the software center or add-apt-repository, the key is installed automatically.
Ubuntu users that never added a repository (PPA) to their system should have all necessary keys.
Users that actually use repositories without having imported a signing key see a warning along the lines below when installing from those repos:
You are about to install software that can't be authenticated! Doing
this could allow a malicious individual to damage or take control of
your system.
CVE-2014-0487
If a hash in the Release file changes, but the file being referred to by the Release file gets served with a 304 response (http status code 304), apt ignored the updated file and continued to use the old version of the file, even though the old version of the file didn't match the new hash.
Source
If an attacker somehow had managed to make you download a malicious package, said attacker could make your system use the old, malicious, files that had already been downloaded, instead of a more recent file available from the repo.
If you never used repositories without having a valid signing key for the repo, you're probably not affected.
CVE-2014-0488
It was discovered that APT did not properly invalidate unauthenticated data. Imagine that you use an unauthenticated repo. You download / install / ... packages from that repo and only later add a signing key for that repo.
All the data that's already been downloaded is just kept. It is theoretically possible, that you have downloaded forged data, because at the time you were unable to verify that (due to the lack of a signing key). Now apt would be able to verify the downloaded data, but it didn't. (Instead it could also just throw away everything downloaded from that repo and download new, this time - with a signing key present - it could verify the downloads).
If you never used repositories without having a valid signing key for the repo, you're probably not affected.
CVE-2014-0489
There's an option called Acquire::GzipIndexesin apt. This option disabled by default.
Here's what the manpage says about it:
GzipIndexes
When downloading gzip compressed indexes (Packages, Sources, or
Translations), keep them gzip compressed locally instead of
unpacking them.
The issue was, that if you had set this to yes, then the checksum check was not performed, leading to potentially forged packages being downloaded / installed / ...
Personal note: I could not find if Acquire::CompressionTypes::Order:: "gz"; also skipped the checksum check.
If you never set Acquire::GzipIndexes in your apt.conf, you're probably not affected by this issue.
CVE-2014-0490
You can use apt-get download to download packages. If you do so and do not have the repository signing key, then you download packages which you can't verify the integrity of (because you lack the key). In this case, apt should have warned you that you're doing something potentially unsafe, so you can think twice about installing these packages.
The issue is: apt didn't notice the user.
If you never used apt-get download, you're probably not affected by this issue.
Patches
Click here to see the relevant patchset for Debian.
My statements are purely informational, do not rely on them
