Security researchers have proposed several methods for users to protect their computers from ongoing attacks that target a new and yet-to-be-patched vulnerability in all versions of Java Runtime Environment 7.
Most of the proposed solutions have drawbacks or are applicable only to certain system configurations and environments. However, the hope is that in the absence of an official patch from Oracle users will be able to use one or a combination of them in order to reduce the risk of their systems being compromised.
Researchers from security firm FireEye announced the existence of the new Java vulnerability on Sunday and reported that it's being exploited in limited targeted attacks.
A working proof-of-concept exploit appeared online the next day and was integrated into Metasploit, an open-source security testing tool used by many penetration testers.
The new vulnerability is considered extremely critical and can be exploited to execute malicious code on a system by simply visiting a maliciously crafted Web page from a Web browser that has the Java plug-in enabled.
The only recommendations that most security professionals have given to users in order to protect their systems from attacks targeting this vulnerability was to uninstall Java or at least disable the Java Web plug-in from their browsers.
Instructions on how to do the latter for the most popular Web browsers are detailed in an advisory published by the United States Computer Emergency Readiness Team (US-CERT) on Monday.
This is probably the most effective method of mitigating the risks associated with the Java new vulnerability or similar ones that might be discovered in the future.
However, it has the drawback of not being practical in some environments, especially business ones where Java-based Web applications are necessary for important operations.
"Most consumers never need Java, but many corporate users require it for things like GoTo Meeting and WebEx," Chester Wisniewski, senior security adviser at antivirus vendor Sophos, said Tuesday via email. "In a corporate environment you may be able to control JavaW.exe and make sure it will only execute certain applets or contact known good IP ranges for services you use that require Java."
Another solution was proposed by Wolfgang Kandek, the chief technology officer at security vendor Qualys, and consists of using the Zone-based security mechanism of Internet Explorer to in order to restrict which websites that can load Java applets.
Users can forbid the use of Java in the Internet Zone by setting the Windows registry key 1C00 to 0 under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 and allowing Java only on whitelisted websites in the Trusted Zone, Kandek said Monday in a blog post.
Meanwhile, users of Google Chrome and Mozilla Firefox can achieve a similar result by enabling the click-to-play feature that blocks plug-in-based content from loading by default and asks for user confirmation. The feature allows website white-listing.
Chrome has supported "click to play" for a long time and enabling it can easily be done from the advanced settings interface. However, in Firefox the feature is still a work in progress and can only be activated by switching the "plugins.click_to_play flag" -- only available in Firefox 14 and above -- to "true" in the "about:config" interface.
The popular NoScript security extension for Firefox also forces click-to-play behavior for plug-in-based content and other extensions that provide similar functionality are available for download from the Mozilla add-ons repository.
"Click to play" blocks the automatic exploitation of this vulnerability, but does not prevent users from manually allowing malicious applets to execute when prompted to take a decision about them. Therefore, the task of assessing the risk ultimately falls with the user.
Another user-dependent way of reducing the risk of encountering a malicious Java applet is to use one Web browser with Java disabled for general browsing and another one with Java enabled only for accessing trusted Java-based Web applications.
Such a policy might be hard to enforce on a business network. However, it might be practical for security-conscious users who need to use certain Web-based Java applications from their personal computers on a regular basis.
Finally, there is an unofficial Java patch created by Michael Schierl, a security researcher who found other Java vulnerabilities in the past, that is being distributed by independent security researchers Andre' M. DiMino and Mila Parkour from DeepEnd Research.
The patch appears to block the exploit used in the attacks seen so far, but its creator doesn't guarantee that it will block all ways of exploiting this vulnerability that might be used in future exploits.
The patch was only subjected to limited testing and, as any unofficial patch, comes with no guarantee that it won't prevent legitimate programs from working properly after it is deployed. Because of this, DiMino and Parkour are only giving it to companies that email them and clearly explain the reasons for needing it.
If there is any conclusion to draw from these proposed mitigation methods is that none of them will fit everyone's needs.
"The most appropriate strategy is going to vary greatly depending on your organization's security posture as well as the extent you are using Java in business critical apps," Stephen Cobb, a security evangelist at antivirus vendor ESET, said Tuesday via email. "All of which makes endorsing a specific strategy for everyone impractical."
Many security experts, including Wisniewski and Cobb, believe that Oracle should break out of its regular 4-month patching cycle and fix this vulnerability as soon as possible. The next batch of security patches for Oracle products are otherwise scheduled to be released in October.
