Details of New Java Exploit Emerge

More details about the new Java zero day vulnerability are emerging, and as the seriousness of the problem has become clear, researchers have recommended that users disable Java altogether for the time being if they don’t have a specific need for it. 

More details about the new Java zero day vulnerability are emerging, and as the seriousness of the problem has become clear, researchers have recommended that users disable Java altogether for the time being if they don’t have a specific need for it. 

The vulnerability in Java first emerged late Sunday as researchers began seeing evidence of exploits targeting a new, unknown flaw. Several researchers quickly analyzed the attacks and found that they were using the vulnerability in drive-by download style attacks that eventually resulted in the installation of the Poison Ivy remote-access tool. The attacks currently are emanating from a domain in China. 

Because Java is one of the more widely deployed applications on the Web, the potential for widespread attacks using this vulnerability is quite large. The vulnerability only affects Java 7, researchers say, but there is working exploit code available, and there also is a module available in Metasploit for the flaw.

The team at DeepEnd Research has published a detailed analysis of the vulnerability by Michael Schierl, a German developer who has done quite a bit of work on Java vulnerabilities in the past. Schierl found that the attack code is employing a somewhat novel technique in order to accomplish its goals. 

“A Statement is created that disables the security manager (by default with permissions of the untrusted code). But before calling the statement, the permissions stored in that field we just got access to are overwritten with permissions that allow running all code, and the statement can be called now and disable the security manager for us. At this point, no security manager is left, and the applet can do anything Java can,” Schierl wrote in his analysis.

“This method of abusing restricted package permissions is new to me (it does not work in Java 6 either as GetField was private there); but it is not unique – there are several ways you can use to get out of the sandbox if you have access to restricted packages – usually they need a bit more code though.”

Researchers who have tested the exploit say that it works reliably on Internet Explorer and Firefox on Windows 7 and Metasploit’s module also works on Chrome on Windows XP. DeepEnd has access to a third-party patch, produced by Schierl, that organizations can request on an individual basis. Barring that, the best advice right now is to disable Java altogether if there isn’t a pressing need to have it running.

Suggested articles

Discussion

  • Anonymous on

    The right question however would be, does KAV 2013 new Automatic Exploit Prevention block it? Or if not, is it able to get autoupdated and be able to block it? :)

  • Macho the dog on

    What is a decent alternitive?

     

  • Anonymous on

    The answer to the first question seems to be "yes it does"!

    securelist.com/en/blog/208193822/The_Current_Web_Delivered_Java_0day

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.