Slashdot Mirror

Really.

http://blog.cr0.org/2010/04/javacalypse.html

I actually got one of my systems pwned (for the first time in > 10 years) via Chrome, in incognito mode no less. Not saying that any other browser would have stopped it, least of all IE; it was a Java -- not javascript -- vulnerability... http://blog.cr0.org/2009/05/write-once-own-everyone.html. This vulnerability allowed an applet to escape both Chrome's and Java's sandboxing. The point is just that no browser is by itself a silver bullet of invulnerability, especially when plugins and external runtimes are involved.

Set up a virtual-box VM and browse from there. That's a pretty decent level of sandboxing. You can make it look like a native window / native app with the HOST+L key.

I actually got one of my systems pwned (for the first time in > 10 years) via Chrome, in incognito mode no less. Not saying that any other browser would have stopped it, least of all IE; it was a Java -- not javascript -- vulnerability... http://blog.cr0.org/2009/05/write-once-own-everyone.html [cr0.org]. This vulnerability allowed an applet to escape both Chrome's and Java's sandboxing.

... and the fact that this happened while you were using Chrome's "incognito mode" is a good indication of the types of sites that you were visiting when this happened.

Look - wearing a bullet-proof vest does offer a degree of protection greater than normal clothing, but that doesn't mean that you should be walking around the red-light district of Oakland, CA after dark. You can still get knifed, kidnapped, or shot in the head. It also won't protect you from the impact of hitting the ground after jumping out of an airplane without a parachute.

No tool is invulnerable, and no tool will protect you from risky behavior.

+1.

I actually got one of my systems pwned (for the first time in > 10 years) via Chrome, in incognito mode no less. Not saying that any other browser would have stopped it, least of all IE; it was a Java -- not javascript -- vulnerability... http://blog.cr0.org/2009/05/write-once-own-everyone.html. This vulnerability allowed an applet to escape both Chrome's and Java's sandboxing. The point is just that no browser is by itself a silver bullet of invulnerability, especially when plugins and external runtimes are involved.

Now I run Chrome standalone with the -disable-java command line switch to cut the attack surface down a bit. It's not as versatile as NoScript in FF, but you can run Chrome instances with javascript, plugins, etc. disabled on an individual basis. A list is at http://www.chromeplugins.org/tips-tricks/chrome-command-line-switches/.

That doesn't mean there a other problems, a very good example:

http://blog.cr0.org/2009/05/write-once-own-everyone.html

...but I didn't have a mac, so I had to use a vm with an unpatched linux (ubuntu 8.10 actually). I tried to convince a guy with a mac in the audience to go to my exploit url, but he was not willing... One cool thing of this exploit is that it is pure java, so the same exploit can work on linux, mac and windows.

Here is a writeup on the vulnerability: http://blog.cr0.org/2009/05/write-once-own-everyone.html

And here is a proof-of-concept exploit: http://landonf.bikemonkey.org/code/macosx/CVE-2008-5353.20090519.html

You can decompile it to see what's going on exactly.

Enjoy.

So MacOS X users, please disable Java in your web browser. Others: make sure you have updated Java and still disable it in your web browser: it's a huge attack surface and it suffers from many other security vulnerabilities.

Oh, and to all who pointed out that Sun had patched this months ago - have you updated Java since then?

for various reasons, Java is usually poorly updated:

• The Sun Java update mechanism isn't tied to the operating system update system on the Windows platform. Personal users and companies don't update it often, some of them do have processes in place to deal with Microsoft's patch Tuesdays but don't for other software updates.
• Many companies are using web applications or Java software that rely on a specific Java version. It may be tedious to update Java because it would break many things. This may be the reason why Apple's Java updates are so infrequent.
• Some Linux distributions don't support Sun's JRE (proprietary software) despite making it available. When I asked Ubuntu to fix this vulnerability, they fixed OpenJDK quickly but told me the Sun JRE was not supported (despite being available by default on the latest LTS Ubuntu release).

I'm not trying to grief, and it is certainly consistent with reality, but is this documented anywhere?

Sure. Only Apple can release java for mac. Something about look & feel and/or quality assurance.

http://blog.cr0.org/2009/05/write-once-own-everyone.html
http://java.dzone.com/news/critical-mac-osx-java

Look at the "java downloads for all operating systems" webpage:

http://www.java.com/en/download/manual.jsp

Notice that you can't download java for mac from Sun?

technical details here.

The gist of it that the Java Calendar code temporarily elevates its privileges in order to deserialize a ZoneInfo object. If you substitute your own object's serialization for the ZoneInfo, you can get the Java runtime to create any object you want. Some questions:

1. Didn't anyone realize how dangerous arbitrary privilege elevation is?
2. Didn't anyone think that it might be overkill to elevate privileges in order to read a timezone?
3. How many other similar vulnerabilities are lurking in the standard library?