URGENT: Unconfirmed Reports QuickTime Exploit Capture Is Circulating
Thomas Ptacek | April 25th, 2007 | Filed Under: Apple, Uncategorized
Remember what I said about “living dangerously”? Stop living dangerously, right now. Turn Java off in your browser. Watch this space for more details.
[Update: 1:43 EST]
There are unconfirmed reports, from multiple credible sources, that the challenge MacBooks from the contest were exposed to an unprotected wireless network, and that raw packet captures of the successful exploit have been taken by parties unknown to us.
We’re looking for comments from people involved with the contest for more details about the network topology so we can confirm this.
There’s a difference between the exploit being captured and the exploit being successfully hosted by attackers in the wild. Even so, this is a particularly virulent problem. It affects every mainstream browser on every mainstream desktop platform —- possibly excepting Vista. Disable Java in your browser until you’ve received a patch.
[Update: 1:30 EST]
InfoSec Sellout is blogging that they’ve reversed the vulnerability and also captured all the packets from the conference. Those claims have not been verified. InfoSec Sellout is not one of our sources. Their claims aren’t corroborated by any of the public record about the vulnerability, which, contrary to their report, doesn’t appear to involve “the way QuickTime handles Javascript”.
[Update: 2:30 EST]
Comment reprinted in its entirety, contradicting claims that the exploit could have been captured off the CanSec wireless network:
Someone may have reverse-engineered the vulnerability but they didn’t pull it off the network there. The network was very simple: a WAP that was connected to a hub and to the router to provide Internet access. The Macs sat on the hub and the only other systems on there were the ones we used to monitor the network to ensure rules were followed and then K2’s when he ran the exploit. The WAP was routing traffic from the hub to the Internet, not sending it out over the wireless network.
We were sniffing the traffic on the wireless network and would have noticed if it had been getting traffic from the wired side.
Y’all know routing & switching protocols well enough to know that traffic destined for the Internet wouldn’t end up on the pocket wireless network. The AP doesn’t have enough smarts to mess up routing that way unless someone owned it (which is admittedly possible).
The point is, no one sitting on the wireless network would have been able to sniff the traffic from the wired network to the Internet.
[Update: 2:40EST]
This is turning into a game of telephone. We’re tracking a variety of reports both confirming and denying that information about the exploit has leaked. We have no confirmation that anybody besides 3Com and the affected vendors have details about this exploit. We think it’s important to be aware that there’s controversey about whether that’s the situation: if this exploit has leaked to the wild, it is very important that you update your browser configuration.
We’re going to ratchet down the up-to-the-minute Drudge Report updates on this aspect of the story until we can confirm more details, but we’ll update this post as soon as we have something conclusive.
[Update: 6:55EST]
The bulk of the “it leaked!” leads in this soap opera are not panning out, fortunately for all involved. We’ll post a round-up of the stuff that did happen later on.
luc
April 25th, 2007 1:25 pmI’m using IE7 in Windows Vista and so I’m not affected
Thomas Ptacek
April 25th, 2007 1:26 pmYou don’t know that, yet.
carl
April 25th, 2007 1:52 pmWhy Should I disable Java? The flaw is in Apple QuickTime and so I disable QuickTime
Thomas Ptacek
April 25th, 2007 1:56 pmYou can remove QuickTime as well, and that will also solve the problem. It’s harder to do that than to click the Java checkbox in the browser, which is why we’re recommending it.
Jon Bowie
April 25th, 2007 1:56 pmI’ve used the NoScript Firefox plugin for awhile now:
http://noscript.net/
By default it completely disables javascript, allowing for user-based manual exclusion of sites you trust.
I haven’t audited it, so caveat emptor.
Thomas Ptacek
April 25th, 2007 1:58 pmYou don’t need to disable Javascript. Javascript and Java are unrelated.
Jon Bowie
April 25th, 2007 2:04 pm“The NoScript Firefox extension provides extra protection for Firefox, Flock, Seamonkey and others mozilla-based browsers: this free, open source add-on allows JavaScript and Java execution only for trusted domains.”
It includes Java.
Drew Thaler
April 25th, 2007 2:04 pmJavaScript and Java have absolutely nothing in common except a poorly-chosen name. Disabling JavaScript (directly or via NoScript) has no effect on Java code.
toby
April 25th, 2007 2:29 pmSomeone may have reverse-engineered the vulnerability but they didn’t pull it off the network there. The network was very simple:
a WAP that was connected to a hub and to the router to provide Internet access. The Macs sat on the hub and the only other systems on there were the ones we used to monitor the network to ensure rules were followed and then K2’s when he ran the exploit. The WAP was routing traffic from the hub to the Internet, not sending it out over the wireless network.
We were sniffing the traffic on the wireless network and would have noticed if it had been getting traffic from the wired side.
Y’all know routing & switching protocols well enough to know that traffic destined for the Internet wouldn’t end up on the pocket wireless network. The AP doesn’t have enough smarts to mess up routing that way unless someone owned it (which is admittedly possible).
The point is, no one sitting on the wireless network would have been able to sniff the traffic from the wired network to the Internet.
Rosyna
April 25th, 2007 2:42 pmThomas, so we can continue to live dangerously? Throw caution to the wind? Have our cake and eat it too?
Also, how about we just call it Java and ECMAScript from now on? The latter is probably more accurate as well.
Rosyna
April 25th, 2007 2:47 pmIt’s very, very possible that someone is “auditing” a reverse engineer of various libraries based on the crash log snippets posted earlier. While they won’t help much, they may help just enough. I even thought about using them to find what’s what. But then I figured it’d take too much time to reproduce the exact config in order to make it easier for me. Laziness wins again.
Also, people could just be searching the various codepoints like crazy trying to find anything that could resemble this bug.
Thomas Ptacek
April 25th, 2007 2:47 pmNo. Definitely stop living dangerously. I feel dumb for being cavalier about this finding.
Chris Rohlf
April 25th, 2007 2:59 pmOk too many people are saying too many things and I have been out of the loop this week, busy with other things. Firefox on Linux, vulnerable? Not vulnerable? Thanks
Thomas Ptacek
April 25th, 2007 3:00 pmNo confirmation of Linux. What’s the disposition of QuickTime on Linux?
Again, as regards vulnerability details: it requires Java and QuickTime, and has been confirmed on FF/X, FireFox, Safari, IE6, and IE7 XP.
carl
April 25th, 2007 3:00 pmFirefox is vulnerable, with or without NoScript.
Chris Rohlf
April 25th, 2007 3:03 pmOk so quicktime is required, I am saved via lack of functionality and support
thanks
Jordan Wiens
April 25th, 2007 3:17 pmIt seems like the the advanced no plugins, no java, and no flash options in noscript would be preventative enough. Whether it’s an embedded quicktime object or embedded java applet, both are blocked by a recent noscript with those options on.
Don jackson
April 25th, 2007 3:33 pmCould you simply rename the “QTJava.zip” file and continue to use Java as you normally would? I don’t like that you’re advising to disable one vendor’s software in order to protect against a vulnerability in another vendor’s product.
Thomas Ptacek
April 25th, 2007 5:06 pmI don’t like it either, but them’s the breaks. Matasano isn’t directly involved in this exercise; we’re just reporting what we hear.
The problem is that we’ve confirmed that disabling Java (or QuickTime) mitigates the vulnerability, but haven’t firmed deleting specific Java components will. I totally believe your solution could work, but I can’t confirm it.
links for 2007-04-25 « it’s hard to be a bot on #fsav_linux
April 25th, 2007 6:28 pm[…] 17 Comments so far (tags: 21:56 <@timo_tm> ircchannel:#fsavlnx ircnick:timo_tm) […]
John Herron
April 25th, 2007 6:38 pmThe latest versions of NoScript can block Java (as well as JavaScript, Flash, other Plugins, and some XSS. You have the option to allow these for “trusted” sites. See the screen shot under mitigation that I posted: http://www.nist.org/news.php?extend.226
If the browser never processes the Java code it can’t pass it on to Quicktime. You may want check the box to not allow any plugins on untrusted sites just in case.
David Schor
April 25th, 2007 8:08 pmAny news on whether this exploit works on PPC machines?
Hash
April 25th, 2007 9:06 pmIf it’s a Java bug, I don’t see why it wouldn’t.
Remember, Java’s selling point was write once run anywhere.
Ryan Russell
April 26th, 2007 12:48 amPossibly because it’s a Quicktime vuln, and not a Java vuln? If it’s a shellcode-based exploit, maybe you can use Java to cross-platform shove code at it, but that doesn’t necessarily mean it’s going to execute.
HAL
April 27th, 2007 12:35 pmCue Lalo Shiffrin soundtrack…. you may want to consider moving to a virtual env altogether, and ask yourself where your hardware came from, for starters.
Summer should be a fun time.
H
David Schor
May 1st, 2007 5:09 pmUpdate - QuickTime 7.1.6 has been released today, and apparently fixes the problem. Kudos to Apple.
Leave a reply