Java bug exposes users to serious code-execution risk
Researchers disclose because Oracle won't
Researchers have discovered a flaw in the latest version of Oracle's Java runtime environment that attackers can exploit to remotely execute malicious code on end user machines.
The bug in the Java Web Start component has been confirmed exploitable on all recent versions of Windows by Tavis Ormandy, a security researcher who prefers his employer not be named. Fellow researcher Ruben Santamarta of Spain-based security firm Wintercore, said a related flaw potentially affects Linux users as well.
Both researchers stressed the ease in which attackers can exploit the bug using a website that silently passes malicious commands to various Java components that jump-start applications in Internet Explorer, Firefox, and other browsers. Ormandy said he alerted Java handlers in Oracle's recently-acquired Sun division to the threat but "they informed me they do not consider this vulnerability to be of high enough priority to break their quarterly patch cycle."
Both researchers criticized the reaction.
"The method by which Java Web Start support has been added to the JRE is not less than a deliberately embedded backdoor (I really don't think so) or a flagrant case of extreme negligence (+1)," Santamarta wrote here. "It's even more incredible that Sun didn't assess the real risk of this flaw after Tavis reported it to them."
The vulnerable Windows components uncovered by Ormandy include an ActiveX control known as Java Deployment Toolkit and a Firefox plugin known as NPAPI, which are designed to make it easy for Java developers to distribute their applications to end users. These components accept commands embedded in web pages or URLs without proper scrutiny and then pass them to another component for execution.
A hidden command-line parameter supported by Java can trigger the bug on Linux machines as well, Santamarta told The Register. He said he was in the process of testing whether the flaw can be exploited to remotely execute code.
Ormandy warned that it won't be easy for users to protect themselves from the vulnerability short of installing a patch. Merely disabling ActiveX or Firefox plugins isn't enough because the toolkit is installed separately from Java. That means the only temporary fixes are browser specific for IE and Firefox and involve setting killbits or employing file system access control list features. (More about that here).
Of course, there's another mitigation that was tweeted Friday by security researcher Alex Sotirov that's looking more and more viable.
"I uninstalled Java more than a year ago and haven't had a single problem with any website," he wrote. "Why are people still running Java in the browser?"
Good question. ®
"Why are people still running Java in the browser?"
...because they might need to, oh, I don't know, administer Cisco devices?
Retarded rhetorical question is retarded.
there must be a lot of "no ones"
there are 10's of millions of jre downloads every month, so clearly Java is used. If you surf the web you are using Java, maybe not on the desktop but on the back end it is in wide spread use. But I do also run into java on the web all the time, I have the console open so I see when it's running.
You'll be seeing more of it...
If this is a Java Web Start issue then it's not really "Java in the Browser" - it's a way of downloading and installing Java applications (not applets) from a website onto the Desktop in a standard format. Why would you want this? Ever done a rollout to 10,000 desktops?
Java's natural home is definitely on the server, but a lot of changes in 1.6.0_16 make the applet experience much better than the crappy "Nervous Text" type stuff you may remember from 5 years ago - startup is much quicker and easier than it was, although still not as transparent as Flash.
Having said all that Java Web Start still has issues - we've modified our App to work with it but it does feel a bit beta stilll - and this story isn't too surprising. Sun really, really cocked up Java on the Desktop.