Wed 16 Jan 2013
I don’t like to go into too much detail about security updates, but I think it’s necessary to point out a few facts about the one we released yesterday, given some of the inaccuracies I’ve seen been spread on Twitter and elsewhere.
Patches were belatedly approved for OpenJDK 7u. OpenJDK 6 is not affected.
- 8004933: Improve MethodHandle interaction with libraries
- 8006125: Update MethodHandles library interactions
Running Java code from the command-line is quite different from running it via a browser plugin. In the latter situation, the user generally does not invoke the code and it runs in a sandbox with a much restricted set of privileges. Security issues occur when ways are found of achieving privilege escalation and being able to do thiings from the browser plugin that shouldn’t be allowed, such as invoking a program on the user’s computer. Bugs that allow this have a much higher security impact. Such escalation is fairly irrelevant when running Java from the command line as generally users run without a security manager and the code has full privileges anyway.
It is generally advisable to only run plugins in the browser that are needed (this applies to both Java and others such as Flash) and, where possible, whitelists should be used so that plugins are only used on pages approved by the user (of course, this depends on how informed the user is about giving such approval). So, all these advisories to turn off the Java browser plugin have some merit, as if you don’t use the plugin, you won’t be hit by browser-based exploits from either this issue or any future issues which may occur. Some people, of course, have no choice but to use the plugin, as some sites they use require it. In these situations, the plugin should only be used on those sites and disable for others; browsers such as Firefox and Chromium are now starting to provide users with more options (such as ‘click to play’) as to when and where plugins are invoked, and this will also help with security issues.
As always, any opinions expressed here are my own, and not those of Red Hat, Inc.