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