DISQUS

luc · 2 years ago

I'm using IE7 in Windows Vista and so I'm not affected

Thomas Ptacek · 2 years ago

You don't know that, yet.

carl · 2 years ago

Why Should I disable Java? The flaw is in Apple QuickTime and so I disable QuickTime

Thomas Ptacek · 2 years ago

You 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 · 2 years ago

I'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 · 2 years ago

You don't need to disable Javascript. Javascript and Java are unrelated.

Jon Bowie · 2 years ago

"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 · 2 years ago

JavaScript 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 · 2 years ago

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.

Rosyna · 2 years ago

Thomas, 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 · 2 years ago

It'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 · 2 years ago

No. Definitely stop living dangerously. I feel dumb for being cavalier about this finding.

Chris Rohlf · 2 years ago

Ok 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 · 2 years ago

No 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 · 2 years ago

Firefox is vulnerable, with or without NoScript.

Chris Rohlf · 2 years ago

Ok so quicktime is required, I am saved via lack of functionality and support :D thanks

Jordan Wiens · 2 years ago

It 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 · 2 years ago

Could 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 · 2 years ago

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

John Herron · 2 years ago

The 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 · 2 years ago

Any news on whether this exploit works on PPC machines?

Hash · 2 years ago

If 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 · 2 years ago

Possibly 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 · 2 years ago

Cue 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 · 2 years ago

Update - QuickTime 7.1.6 has been released today, and apparently fixes the problem. Kudos to Apple.