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.
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.
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.)
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!
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/
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.
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.
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.
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.
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.
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.
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?
Doesn't the NHS sell anonymized data from their health system in the UK? Can't we train Watson off of that data?
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.
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.)
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.
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?
36 comments
[ 70.8 ms ] story [ 342 ms ] threadIt seems all my default repositories are http, and not https as I had initially assumed, so this seems pretty bad.
No.
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.
Spelling out my derp in case someone else had the same thought.
Also, ProjectZero...
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.
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.
We've been saying this for nearly 70 years. I'm still waiting.
The future is already here.
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.
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.
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.
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?
For example, you can see the change in cdrom: handling code as mentioned in the security notice.
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/
edit: though aptitude depends on libapt-pkg, so quite possibly this bug affects aptitude too :(
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...
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...