
CVE-2014-6273: Buffer overflow vulnerability vulnerability in apt-get - anon1385
https://lists.debian.org/debian-security-announce/2014/msg00219.html
======
jimrandomh
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
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...](https://launchpad.net/ubuntu/trusty/+source/apt/1.0.1ubuntu2.4.1)
[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-20...](http://people.canonical.com/~ubuntu-
security/cve/2014/CVE-2014-6273.html)

------
tokenizerrr
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.

~~~
philsnow
[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
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.

------
yeukhon
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...

~~~
valarauca1
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
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.

~~~
Phlarp
Machine learning applied to vulnerability research in open source code
distributions =/= strong AI.

~~~
toomuchtodo
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.

~~~
valarauca1
>but who knows. Technology is moving pretty damn fast.

We've been saying this for nearly 70 years. I'm still waiting.

~~~
toomuchtodo
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.

~~~
roywiggins
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.

------
tjbiddle
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
This diff appears to contain the patch:
[https://launchpadlibrarian.net/185571456/apt_0.7.25.3ubuntu9...](https://launchpadlibrarian.net/185571456/apt_0.7.25.3ubuntu9.17_0.7.25.3ubuntu9.17.1.diff.gz)

For example, you can see the change in cdrom: handling code as mentioned in
the security notice.

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

------
jessaustin
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
Nope; that looks like a typo.

------
tsomctl
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
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...](https://mirrors.ocf.berkeley.edu/debian-
security/pool/updates/main/a/apt/apt_0.9.7.9+deb7u5_amd64.deb) (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...](https://lists.debian.org/debian-
release/2014/09/msg00292.html)

------
infinity0
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
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 :-)

