6 ms·

CVE-2014-6273: Buffer overflow vulnerability vulnerability in apt-get

72 points by anon1385 12y ago

tokenizerrr 12y ago
Is there any evidence of this having been used in the wild anywhere? If I understand correctly it could have been exploited by people running http apt repositories, or those intercepting the connection? It seems all my default repositories are http, and not https as I had initially assumed, so this seems pretty bad.
- DrewHintz 12y ago
  > Is there any evidence of this having been used in the wild anywhere? No.
- philsnow 12y ago
  https://wiki.debian.org/SecureApt https://wiki.debian.org/SecureApt Upshot is, apt doesn't need to be served over https because when it fetches Release, it also fetches Release.gpg and verifies the signature contained therein. If it can't fetch or the sig doesn't verify, it squawks.
  - AceJohnny2 12y ago
    I was going to say: "but if you get MITMed, the attacker can replace the Release.gpg as well", but clearly I didn't understand GPG signage: an attacker won't have Debian's private keys and so won't be able to produce valid signatures. Spelling out my derp in case someone else had the same thought.
  - agwa 12y ago
    Also, if apt did use HTTPS, it would make client-side vulnerabilities like this one even more likely, since you'd have an entire TLS implementation to contend with. (Though there is certainly some value in using HTTPS to hide what packages you're downloading.)
  - disjointrevelry 12y ago
    That is how it works, unless there's a buffer overflow that allows installing undetected corrupted packages. One of things that is surprising about apt-get and its integrity of debian/ubuntu, is nothing requiring root permissions should ever connect to the 'net, let alone download and execute!
yeukhon 12y ago
How did they even discover this in the first place? Fuzzing every software they use? I know Google has a team dedicated to find exploits...
- krasin 12y ago
  I guess it's related to Project Zero: http://googleprojectzero.blogspot.com/ http://googleprojectzero.blogspot.com/
  - DrewHintz 12y ago
    It's not actually related to Project Zero. There are quite a few people here at Google, both on Project Zero and on other projects and teams, that routinely find vulnerabilities. Here's a list of some of the vulnerabilities: http://www.google.com/about/appsecurity/research/ http://www.google.com/about/appsecurity/research/
- chadillac 12y ago
  They are very likely maintaining their own apt repos internally, might have been a bug in one of their packages or something that triggered quirkiness, warranting review. Also, ProjectZero...
- valarauca1 12y ago
  They may have found a way to automate testing software that's more in-depth then say valgrind. Maybe involving machine learning. Most buffer overflow exploits likely rely on common patterns in source code (if you ignore variable names). Which could be taught to a computer. Actually 90% of buffer overflows result in the length of your read and the place of read coming from highly independent sources.
  - toomuchtodo 12y ago
    I just got a shiver thinking about Google's machine learning ingesting most of GNU/Linux source code from distros, and "learning" how to write software better than a human.
tjbiddle 12y ago
I can't seem to find a link to the patch - I'd like to take a look at the fix. Anyone know where I could find it?
- DrewHintz 12y ago
  This diff appears to contain the patch: https://launchpadlibrarian.net/185571456/apt_0.7.25.3ubuntu9.17_0.7.25.3ubuntu9.17.1.diff.gz https://launchpadlibrarian.net/185571456/apt_0.7.25.3ubuntu9... For example, you can see the change in cdrom: handling code as mentioned in the security notice.
  - agwa 12y ago
    That doesn't contain the buffer overflow fix. You can tell from the diff of the changelog that the fix is already there.
- agwa 12y ago
  Here's a diff between apt-0.9.7.9+deb7u4 and apt-0.9.7.9+deb7u5, obtained via `apt-get source`: https://gist.github.com/AGWA/4069e45856ed261ac0af https://gist.github.com/AGWA/4069e45856ed261ac0af You can see the change from a fixed-length buffer to a std::string. This is apt's Git repo, but the commit hasn't landed there yet: https://anonscm.debian.org/cgit/apt/apt.git/ https://anonscm.debian.org/cgit/apt/apt.git/
jessaustin 12y ago
Is the doubled "vulnerability" in the title supposed to mean anything? As if this could only be a problem when used in concert with another vulnerability? Because if that's what it's supposed to mean, I disagree. This vuln by itself is bad.
- david_shaw 12y ago
  Nope; that looks like a typo.
infinity0 12y ago
I wonder if the Google Security Team are reviewing aptitude as well... edit: though aptitude depends on libapt-pkg, so quite possibly this bug affects aptitude too :(
- atmosx 12y ago
  Yeap, I guess they'll do that, if they intend to use it. That's one of the many positive things that come when big corps use open source products :-)
tsomctl 12y ago
The official wheezy ISO is 7.6.0, released in August. Thus it doesn't have a fix for this vulnerability or the one from earlier this month. How do you update to avoid this vulnerability without exposing yourself to it?
- ckuehl 12y ago
  You could mitigate it somewhat by switching your sources to HTTPS, assuming you trust the mirror you're using. (The official ftp.xx.debian.org mirrors don't support this, but some popular mirrors do; you're still at the mercy of your mirror, but not vulnerable to MITM attacks.) You could also download the package via normal HTTP and install it with dpkg: https://mirrors.ocf.berkeley.edu/debian-security/pool/updates/main/a/apt/apt_0.9.7.9+deb7u5_amd64.deb https://mirrors.ocf.berkeley.edu/debian-security/pool/update... (download the appropriate arch, of course) If you're deploying lots of wheezy systems, you could also rebuild the cd images (especially the netboot/netinst ones) very easily; the debian-installer docs are very detailed, and there are only a few steps. Note also that there are discussions for issuing a new release in the near future happening on the mailing list: https://lists.debian.org/debian-release/2014/09/msg00292.html https://lists.debian.org/debian-release/2014/09/msg00292.htm...
jimrandomh 12y ago
The old code (see patch: https://gist.github.com/AGWA/4069e45856ed261ac0af https://gist.github.com/AGWA/4069e45856ed261ac0af) was using sprintf and strcat on a fixed size buffer, which are huge red flags of a type which security-bug-hunting analysis tools know about. The fact that a bug like that was still there means that people are just recently taking a close look at apt, and there are probably more findings to come.
isaack 12y ago
I noticed that Ubuntu only gave the patch for this vulnerability a "low" priority[1]. Furthermore, they state that "The default compiler options for affected releases should reduce the vulnerability to a denial of service". Can someone enlighten me 1) What was the compiler flags used to harden this flaw? 2) Was the same compiler flags used to compile Debian packages? Thanks, [1] https://launchpad.net/ubuntu/trusty/+source/apt/1.0.1ubuntu2.4.1 https://launchpad.net/ubuntu/trusty/+source/apt/1.0.1ubuntu2... [2] http://www.ubuntu.com/usn/usn-2353-1/ http://www.ubuntu.com/usn/usn-2353-1/ [3] http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-6273.html http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20...

72 points by anon1385 12y ago

Is there any evidence of this having been used in the wild anywhere? If I understand correctly it could have been exploited by people running http apt repositories, or those intercepting the connection? It seems all my default repositories are http, and not https as I had initially assumed, so this seems pretty bad.

DrewHintz 12y ago
> Is there any evidence of this having been used in the wild anywhere? No.
philsnow 12y ago
https://wiki.debian.org/SecureApt https://wiki.debian.org/SecureApt Upshot is, apt doesn't need to be served over https because when it fetches Release, it also fetches Release.gpg and verifies the signature contained therein. If it can't fetch or the sig doesn't verify, it squawks.
- AceJohnny2 12y ago
  I was going to say: "but if you get MITMed, the attacker can replace the Release.gpg as well", but clearly I didn't understand GPG signage: an attacker won't have Debian's private keys and so won't be able to produce valid signatures. Spelling out my derp in case someone else had the same thought.
- agwa 12y ago
  Also, if apt did use HTTPS, it would make client-side vulnerabilities like this one even more likely, since you'd have an entire TLS implementation to contend with. (Though there is certainly some value in using HTTPS to hide what packages you're downloading.)
- disjointrevelry 12y ago
  That is how it works, unless there's a buffer overflow that allows installing undetected corrupted packages. One of things that is surprising about apt-get and its integrity of debian/ubuntu, is nothing requiring root permissions should ever connect to the 'net, let alone download and execute!

yeukhon 12y ago

How did they even discover this in the first place? Fuzzing every software they use? I know Google has a team dedicated to find exploits...

krasin 12y ago
I guess it's related to Project Zero: http://googleprojectzero.blogspot.com/ http://googleprojectzero.blogspot.com/
- DrewHintz 12y ago
  It's not actually related to Project Zero. There are quite a few people here at Google, both on Project Zero and on other projects and teams, that routinely find vulnerabilities. Here's a list of some of the vulnerabilities: http://www.google.com/about/appsecurity/research/ http://www.google.com/about/appsecurity/research/
chadillac 12y ago
They are very likely maintaining their own apt repos internally, might have been a bug in one of their packages or something that triggered quirkiness, warranting review. Also, ProjectZero...
valarauca1 12y ago
They may have found a way to automate testing software that's more in-depth then say valgrind. Maybe involving machine learning. Most buffer overflow exploits likely rely on common patterns in source code (if you ignore variable names). Which could be taught to a computer. Actually 90% of buffer overflows result in the length of your read and the place of read coming from highly independent sources.
- toomuchtodo 12y ago
  I just got a shiver thinking about Google's machine learning ingesting most of GNU/Linux source code from distros, and "learning" how to write software better than a human.

tjbiddle 12y ago

I can't seem to find a link to the patch - I'd like to take a look at the fix. Anyone know where I could find it?

DrewHintz 12y ago
This diff appears to contain the patch: https://launchpadlibrarian.net/185571456/apt_0.7.25.3ubuntu9.17_0.7.25.3ubuntu9.17.1.diff.gz https://launchpadlibrarian.net/185571456/apt_0.7.25.3ubuntu9... For example, you can see the change in cdrom: handling code as mentioned in the security notice.
- agwa 12y ago
  That doesn't contain the buffer overflow fix. You can tell from the diff of the changelog that the fix is already there.
agwa 12y ago
Here's a diff between apt-0.9.7.9+deb7u4 and apt-0.9.7.9+deb7u5, obtained via `apt-get source`: https://gist.github.com/AGWA/4069e45856ed261ac0af https://gist.github.com/AGWA/4069e45856ed261ac0af You can see the change from a fixed-length buffer to a std::string. This is apt's Git repo, but the commit hasn't landed there yet: https://anonscm.debian.org/cgit/apt/apt.git/ https://anonscm.debian.org/cgit/apt/apt.git/

jessaustin 12y ago

Is the doubled "vulnerability" in the title supposed to mean anything? As if this could only be a problem when used in concert with another vulnerability? Because if that's what it's supposed to mean, I disagree. This vuln by itself is bad.

david_shaw 12y ago
Nope; that looks like a typo.

infinity0 12y ago

I wonder if the Google Security Team are reviewing aptitude as well... edit: though aptitude depends on libapt-pkg, so quite possibly this bug affects aptitude too :(

atmosx 12y ago
Yeap, I guess they'll do that, if they intend to use it. That's one of the many positive things that come when big corps use open source products :-)

tsomctl 12y ago

The official wheezy ISO is 7.6.0, released in August. Thus it doesn't have a fix for this vulnerability or the one from earlier this month. How do you update to avoid this vulnerability without exposing yourself to it?

ckuehl 12y ago
You could mitigate it somewhat by switching your sources to HTTPS, assuming you trust the mirror you're using. (The official ftp.xx.debian.org mirrors don't support this, but some popular mirrors do; you're still at the mercy of your mirror, but not vulnerable to MITM attacks.) You could also download the package via normal HTTP and install it with dpkg: https://mirrors.ocf.berkeley.edu/debian-security/pool/updates/main/a/apt/apt_0.9.7.9+deb7u5_amd64.deb https://mirrors.ocf.berkeley.edu/debian-security/pool/update... (download the appropriate arch, of course) If you're deploying lots of wheezy systems, you could also rebuild the cd images (especially the netboot/netinst ones) very easily; the debian-installer docs are very detailed, and there are only a few steps. Note also that there are discussions for issuing a new release in the near future happening on the mailing list: https://lists.debian.org/debian-release/2014/09/msg00292.html https://lists.debian.org/debian-release/2014/09/msg00292.htm...

jimrandomh 12y ago

The old code (see patch: https://gist.github.com/AGWA/4069e45856ed261ac0af https://gist.github.com/AGWA/4069e45856ed261ac0af) was using sprintf and strcat on a fixed size buffer, which are huge red flags of a type which security-bug-hunting analysis tools know about. The fact that a bug like that was still there means that people are just recently taking a close look at apt, and there are probably more findings to come.

isaack 12y ago

I noticed that Ubuntu only gave the patch for this vulnerability a "low" priority[1]. Furthermore, they state that "The default compiler options for affected releases should reduce the vulnerability to a denial of service". Can someone enlighten me 1) What was the compiler flags used to harden this flaw? 2) Was the same compiler flags used to compile Debian packages? Thanks, [1] https://launchpad.net/ubuntu/trusty/+source/apt/1.0.1ubuntu2.4.1 https://launchpad.net/ubuntu/trusty/+source/apt/1.0.1ubuntu2... [2] http://www.ubuntu.com/usn/usn-2353-1/ http://www.ubuntu.com/usn/usn-2353-1/ [3] http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-6273.html http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20...