Java 7 Under Attack: Researchers Advise It Be Disabled During The Interim

So far, the vulnerability has been leveraged via Internet Explorer, Chrome and Firefox, and the attackers have reportedly been installing a dropper (Dropper.MsPMs), as well as a piece of malware known as Poison Ivy RAT, or a version thereof.

"IT administrators' only defense at the moment is to limit the use to Java," wrote Wolfgang Kandek, CTO of Qualys, in a posted blog. "This can be implemented by uninstalling Java where not needed or by using the Zone mechanism in Internet Explorer, forbidding Java use in the Internet Zone (setting Registry Key 1C00 to 0 in Zone 3) and allowing it only on white-listed websites in the Trusted Zone."

[Related: Malware Attack Against VMware Limited In Scope ]

Kandek also added that, “for once, users of the older Java v6 do seem to be better off as the vulnerability does not affect that version [or earlier versions] of Java.”

Meanwhile, Andre M. DiMino and Mila Parkour of DeepEnd Research report that although the number of attacks up until now has been relatively low, the volume is expected to escalate "due to the fact that this is a fast and reliable exploit that can be used in drive-by attacks and all kinds of links in emails."

In addition, Java is generally considered to be one of the most widely deployed applications, thereby making this exploit particularly inviting to those who might choose to leverage it.

The bloggers also point out that Oracle's scheduled quarterly patch cycle suggests that a fix might not be available till October unless an emergency patch is issued, though their firm has apparently developed a third-party patch that is available by request. DiMino and Parkour are also echoing the recommendation to disable Java 7 until the situation is resolved.

According to an analysis posted by Michael Schierl, a German developer widely renowned for his expertise in Java vulnerabilities, the malicious code utilizes a somewhat unique approach.

"A Statement is created that disables the security manager (by default with permissions of the untrusted code)," he writes. "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.

"What makes the code a bit more complex is the fact, that the bytecode verifier also tries to verify if you are accessing restricted packages, therefore all access to restricted packages has to be done indirectly (that is also good for obfuscation, but here needed to make the exploit work, too)."

PUBLISHED AUG. 27, 2012