2

Just recently 4 bugs in the Packet Manager Apt (the main in Ubuntu) has been discovered. Especially bad for 12.04 LTS as 4 security holes have been found there.

My question is to what dangers have Apt bugs security holes (USN-2348-1) caused?

The explanations are on http://www.ubuntu.com/usn/usn-2348-1/ are rather brief and only state

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 manually downloading packages using the download command. This issue only applied to Ubuntu 12.04 LTS. (CVE-2014-0490)

Further information i.e. by following to http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-0488.html and then trying to read about the bug on https://bugs.launchpad.net/ubuntu/%2Bsource/apt/%2Bbug/1366702 do not yield information as the launchpad.net site is a dead link.

A response to this question would be to describe what the 4 security wholes would mean by means of an example. Also it would be interesting to know if users that only used apt-get install [packagename] and apt-get update and apt-get dist-upgrade could have been given malicious debfiles or respository listings.

3
+50

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

|improve this answer|||||
  • thank you. Is a valid signing key something special or has that been with every Ubuntu user. Is that "having a valid signing key something" something that would have been true for developers only or for almost each ubuntu user? – humanityANDpeace Sep 25 '14 at 15:27
  • @humanityANDpeace it's something special. They are the keys in the various keyring packages (debian-keyring,ubuntu-keyring, etc.), and those you add manually using apt-key or add-apt-key commands. Having your key in those packages shows a very high degree of trust in you. Not for all developers. – muru Sep 27 '14 at 9:45
  • @muru thank you. So does it mean that not everybody has such valid signing key? – humanityANDpeace Sep 27 '14 at 11:32
  • @Jan can you tell what this means "If you never used repositories without having a valid signing key for the repo, you're probably not affected."? Is being a simple 12.04 user that did a clean/vanila install and then used apt-get update; apt-get dist-upgrade -y now a case of a valid signing key? Also did the bug affect such a user? – humanityANDpeace Sep 27 '14 at 11:35
0

If you are using supported releases of Ubuntu then these & other security flaws of note are usually taken care of promptly. So if security & updates repos are enabled in your sources then staying updated will take care of this & any others.

Ex in apt. -

apt (0.8.16~exp12ubuntu10.20.1) precise-security; urgency=low

  • SECURITY UPDATE:
    • fix potential buffer overflow, thanks to the Google Security Team (CVE-2014-6273)
  • Fix regression in 0.9.7.9+deb7u3 when file:/// sources are used and those are on a different partition than the apt state directoryo (LP: #1371058)
  • Revert FileFd::ReadOnlyGzip change
  • Fix regression when Dir::state::lists is set to a relative path
  • Fix regression when cdrom: sources got rewriten by apt-cdrom add

    -- Michael Vogt Tue, 23 Sep 2014 09:02:26 +0200

apt (0.8.16~exp12ubuntu10.19) precise-security; urgency=low

  • SECURITY UPDATE:

    • incorrect invalidating of unauthenticated data (CVE-2014-0488)
    • incorect verification of 304 reply (CVE-2014-0487)
    • incorrect verification of Acquire::Gzip indexes (CVE-2014-0489)
    • incorrect apt-get download validation (CVE-2014-0490)

    -- Michael Vogt Mon, 15 Sep 2014 08:23:20 +0200

So theses issues were fixed a couple of weeks ago

|improve this answer|||||
  • I disagree, with your statement "So if security & updates repos are enabled in your sources then staying updated will take care of this & any others.". People add PPAs and other repositories, some of which are later abandoned, leading to outdated programs on your system. Plus, "fixed a week ago" is correct, but you also need to consider that CVE-2014-0487 was created on Dec 19th 2013. – Jan Sep 25 '14 at 20:20
  • @Jan it is correct what you say. The question original is regarding the dangers that have been there in between. It is quite clear by itself that updating the flawed parts helps to end the problem. – humanityANDpeace Sep 26 '14 at 8:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.