CVE-2014-6273: Buffer overflow vulnerability vulnerability in apt-get(lists.debian.org)
lists.debian.org
CVE-2014-6273: Buffer overflow vulnerability vulnerability in apt-get
https://lists.debian.org/debian-security-announce/2014/msg00219.html
8 comments
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.
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...
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...
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.
It seems all my default repositories are http, and not https as I had initially assumed, so this seems pretty bad.
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.
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.
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.
Spelling out my derp in case someone else had the same thought.
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!
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.)
> Is there any evidence of this having been used in the wild anywhere?
No.
No.
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...
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.
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.
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.
Machine learning applied to vulnerability research in open source code distributions =/= strong AI.
Well, maybe not yet. I think its silly to start discounting what level of AI we'll be able to develop with enough computing power and storage.
Not to say we'll be able to duplicate biological system levels of computing in silicon, but who knows. Technology is moving pretty damn fast.
Not to say we'll be able to duplicate biological system levels of computing in silicon, but who knows. Technology is moving pretty damn fast.
>but who knows. Technology is moving pretty damn fast.
We've been saying this for nearly 70 years. I'm still waiting.
We've been saying this for nearly 70 years. I'm still waiting.
You can ask your phone for the weather and to change the temperature of your home. You can store your entire music collection on a device the size of a postage stamp (512GB Sandisk MicroSD card). There are cars that can literally drive themselves. There is mini version of the space shuttle that runs completely autonomously in space, and has loitered up there for over a year, waiting to come home when it receives a specially coded signal. IBM has software that is slowly replacing doctors and lawyers.
The future is already here.
The future is already here.
A lot of the modern changes are a difference in size or extent, but not in kind. I mean to say: A small hard drive replacing a massive hard drive is very, very useful. But it's not, by itself, any smarter than the magnetic core storage that filled a room. You could ask your Nokia dumbphone for the weather using a text message 15 years ago. People were wiring their home lighting systems into the internet by the early 2000s. Of course, it was more ad-hoc and expensive then. Now you can go down to Best Buy and buy a home automation kit for a few hundred dollars.
The miniaturization and extension of digital technology into every part of our lives and waking moments is extraordinary. But it's not, by itself, much of a guarantee that we'll see strong AI. It's probably necessary but not sufficient.
The miniaturization and extension of digital technology into every part of our lives and waking moments is extraordinary. But it's not, by itself, much of a guarantee that we'll see strong AI. It's probably necessary but not sufficient.
Most of these things are solved with simple algorithms though. That we are able to solve a lot of these problems is pretty much inevitable as the technology stack grows and we are able to stick stuff together via APIs. These systems may seem smart or intelligent but really they are just a large complex network of systems. There is nothing intelligent about them.
AI of this kind is not just the result of a simple step or several. AI will probably be a revolutionary break through that requires an understanding of intelligence and being, we have not made any significant progress in.
AI of this kind is not just the result of a simple step or several. AI will probably be a revolutionary break through that requires an understanding of intelligence and being, we have not made any significant progress in.
Compilers already do this to an extent.
But overall I don't think computers will be actively creating things for a while yet. Maybe I just believe to much in humanity, or I'm just to jaded from following tech news for too long.
But overall I don't think computers will be actively creating things for a while yet. Maybe I just believe to much in humanity, or I'm just to jaded from following tech news for too long.
I always bring this up on HN, but IBM's Watson can diagnose cancer better than 2nd year med students. It's not sentient, but baby steps!
We are moving forward, but not as fast as much techno-evangelists want you to believe we are.
The crux of the problem is with all medical information Watson has access to only that good. Yet with 1/100th to 1/1000th of the information how is a human doctor better?
The crux of the problem is with all medical information Watson has access to only that good. Yet with 1/100th to 1/1000th of the information how is a human doctor better?
> The crux of the problem is with all medical information Watson has access to only that good. Yet with 1/100th to 1/1000th of the information how is a human doctor better?
Doesn't the NHS sell anonymized data from their health system in the UK? Can't we train Watson off of that data?
Doesn't the NHS sell anonymized data from their health system in the UK? Can't we train Watson off of that data?
Just someone reading source code. Coincidentally, the same way Heartbleed was found.
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...
Also, ProjectZero...
I guess it's related to Project Zero: http://googleprojectzero.blogspot.com/
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/
pwillis@zippy:~$ grep -e "^[[:space:]]\+\(strcpy\|strcat\|sprintf\)" -r apt-1.0.1ubuntu2.1 | wc -l
43
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?
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/
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/
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.
For example, you can see the change in cdrom: handling code as mentioned in the security notice.
That doesn't contain the buffer overflow fix. You can tell from the diff of the changelog that the fix is already there.
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.
Nope; that looks like a typo.
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?
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...
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...
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 :(
edit: though aptitude depends on libapt-pkg, so quite possibly this bug affects aptitude too :(
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 :-)