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 four-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.