By now, our readers have undoubtedly seen the buzz about a serious security vulnerability in Oracle Java, with corresponding exploit code making its way around (in the form of active, in-the-wild attack campaigns, as well as penetration testing tools). If you haven't, the gist is that, due to an issue in the way access control permissions are checked in Java, it is possible for an applet to effectively grant itself full permissions, including the ability to execute commands *outside* of the Java sandbox (an operation that is, of course, typically limited). For those interested, Immunity, Inc., posted an excellent, detailed technical write up (as well as some follow-up information about what else was patched in the recent Java update).
To ensure that CA Veracode customers can continue to use our platform while managing risk from this and other vulnerabilities in the Java Runtime, we've assembled a few pieces of guidance.
First, we recommend that customers apply the recently released Java updates (v 1.7.0_07 and 1.6.0_35) from Oracle, based on their recent blog post, release notes and advisory. For those not using the Java updater tool, the JRE and JDK updates can be downloaded directly, and additional information on how to update is available at Java.com.
Second, a few browser-related suggestions for managing this and future Java issues:
For customers running Firefox, newer versions will, by default, block outdated Java plug-ins from running, though applets may still run if the installed JRE version is not blocklisted. We recommend Firefox users also install the NoScript add-on, which will provide, among other things, the ability to enable Java per-site (such as the CA Veracode platform site).
For Chrome users, most plug-ins, including Java, are set by default to be "click-to-play", meaning that when they're included in a page, running them requires user intervention. We recommend leaving "click-to-play" as the chosen option for this setting.
For Internet Explorer users, it's a bit trickier. As IE handles OBJECT and APPLET elements differently (with regard to security controls), and as there's not an entirely straightforward way to enable Java per-site (see previously linked article), we recommend IE users disable Java entirely, enabling only as needed, or use an alternate browser for sites requiring Java.