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

https://lists.debian.org/debian-security-announce/2014/msg00219.html

by anon1385 • 12 years ago

72 36 12 years ago

lists.debian.org

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.

DrewHintz4• 12 years ago

Is there any evidence of this having been used in the wild anywhere?

No.

philsnow• 12 years ago

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• 12 years 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.

agwa3• 12 years 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• 12 years 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• 12 years 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• 12 years ago

I guess it's related to Project Zero: http://googleprojectzero.blogspot.com/

DrewHintz4• 12 years 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/

chadillac• 12 years 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...

valarauca14• 12 years 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.

toomuchtodo5• 12 years 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.

DrewHintz4• 12 years ago

Just someone reading source code. Coincidentally, the same way Heartbleed was found.

peterwwillis• 12 years ago

  pwillis@zippy:~$ grep -e "^[[:space:]]\+\(strcpy\|strcat\|sprintf\)" -r apt-1.0.1ubuntu2.1 | wc -l
  43

Hmm.

tjbiddle• 12 years 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?

DrewHintz4• 12 years ago

This diff appears to contain the patch: 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.

agwa3• 12 years ago

That doesn't contain the buffer overflow fix. You can tell from the diff of the changelog that the fix is already there.

agwa3• 12 years 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

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/

jessaustin• 12 years 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• 12 years ago

Nope; that looks like a typo.

infinity0• 12 years 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• 12 years 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• 12 years 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• 12 years 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/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.htm...

jimrandomh• 12 years ago

The old code (see patch: 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• 12 years 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... [2] http://www.ubuntu.com/usn/usn-2353-1/ [3] http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20...

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

Related Stories