Another Java Exploit For Sale

tsamsoniw writes "Mere days after Oracle rolled out a fix for the latest Java zero-day vulnerabilities, an admin for an Underweb hacker forum put code for a purportedly new Java exploit up for sale for $5,000. Though unconfirmed, it's certainly plausible that the latest Java patch didn't do the job, based on an analysis by the OpenJDK community. Maybe it's high time for Oracle to fix Java to better protect both its enterprise customers and the millions of home users it picked up when it acquired Sun."

Comments

Re:Kill it with FIRE

[Anonymous Coward]

They should die. There is no reason to do that sort of thing in a browser instead of a standalone client.

Java Sandbox Exploit, Not Java Exploit

[Bob9113]

This is not a bug in Java. It is a bug in the Java browser plugin, called a sandbox exploit.

The Java Virtual Machine (JVM) has access to the filesystem and can fork processes. In an attempt to make this safe to use in a browser, Sun wrote a sandbox, that is supposed to block access to the filesystem and to process execution. The sandbox doesn't work, and may never work. Disabling the Java plugin in your browser is a good thing. It might have been nice if the sandbox worked, but it doesn't. Don't run untrusted code in the JVM, whether in a browser or otherwise -- just like not running untrusted C code.

You can Java on a server, open a port, expose that port to the Internet, and as long as you haven't written a hole, nothing bad will happen. That is because this is not a Java exploit. It is a Java sandbox exploit.

Re:Java Sandbox Exploit, Not Java Exploit

[ChunderDownunder]

I wouldn't be too keen to blame the plugin per se anyway.

The whole Java library (rt.jar and others) relies on a security model. Each class invoked has checks to see if a security manager is running and if yes then possibly deny a request based on permissions.

Poor development practices in not vetting the codebase for security checks have caused this. Specifically, this security breach is via new functionality included in JRE 1.7, where any assumptions of security requirements have been invalidated.

An audit of every class included in the JRE needs to occur with unit tests for expected behaviour inside a sandbox and outside.

Applets in a browser are the most common usage of a SecurityManager but pointing a finger at the plugin itself won't fix the underlying library code...

Re:Kill it with FIRE

[Lennie]

So how many people run Minecraft in the browser ? I thought most run it outside of the browser, right ?

Re:This is insane

[trims]

Simple:

• Oracle completely screwed up the acquisition, and made major changes to the Java division. Management was completely redone, and the release/bug process was made much worse (not that it was great under Sun).
• All the old Sun personnel got pissed off at Oracle, for a variety of reasons. Less than 25% of those there in 2008 are still in the Java division; and, that's from an organization where people averaged 10+ years of work at Sun. Oracle hasn't been able to replace this brain drain, and is unlikely to ever succeed in restaffing to an acceptable level. The JDK codebase is incredibly complex - far worse than practically anything else I can think of, including the Linux kernel. The number of people on the planet who are good VM coders numbers maybe a hundred or two. That's it. And the rest of the organization has been decimated, too.

I worked at Sun for 6 years in the JVM group before the acquisition. I stayed on for another 1.5 years before I left. I only know a handful of people there anymore, and they're staying simply to ride it out to retirement (all are in their 50s). Over three dozen people I used to work with are gone, and there's no decent replacements.

Basically, people used to working "the Sun Way" detested the new "Oracle Way" and decamped en masse between 2009 and 2011. The whole Java division is a shadow of itself, and won't ever recover.