Java plugins unplugged by Mozilla and Apple
Contributed by: Email on 01/12/2013 04:39 PM
[
Comments
]
The latest critical vulnerability in Java to be exploited through the browser has made Mozilla and Apple move quickly to block Java in their browsers. They are joined by the US CERT and German BSIGerman language link calling for users to ensure that Java is disabled in their browser. Although Java is in wide use in enterprise software, its presence on the web is now relatively small so, for most users, there is little to no impact in disabling Java in the browser. All versions of Java are vulnerable, including the most recent, Java 7 Update 10.
Apple updated its XProtect configuration for Mac OS X users by setting the value for the minimum version of Java to be allowed to run to an as yet unreleased version 1.7.10.19. This has the effect of blocking Java in the browser with a "blocked plugin" message, though clicking on the plugin suggests going to Oracle to download an update which isn't available yet. Apple have previously published details of how to completely disable the Java plugin in Safari.
Mozilla's block is a little less effective: the company announced that it had added Java 7 update 9 and 10 and the most recent updates of Java 6 (update 37 and 38) to the list of plugins which require "Click to Play". This protects against drive-by malware, but a malicious site could still use social engineering to convince a user to start a dangerous applet. To fully disable Java, it is recommended that you use the Mozilla "How to turn off Java applets" instructions. These instructions are customized to the operating system and Firefox version users view the page with; for other operating systems and versions, readers should use the selection buttons at the top of the Mozilla article.
Google has not, at the time of writing, taken any action to automatically inhibit the Java plugin from running in its Chrome browser. Chrome users will need follow the instructions from the Google page on Plug-ins. This entails putting chrome://plugins/ in the browser address/search bar, which will display all the installed plugins, searching for Java plugin in the list and clicking on the "Disable" link.
Java 7 Update 10 did add the capability on Windows' Java Control Panel to disable Java in the web browser by deselecting "Enable Java content in the browser". This is the simplest way for Internet Explorer users to disable Java plugins; however, as US CERT points out, bugs in the Java 7 installer may mean the control panel applet is missing. The javacpl.exe applet can be launched manually and is usually found in C:\Program Files\Java\jre7\bin or C:\Program Files (x86)\Java\jre7\bin.
The vulnerability itself has now been identified as making use of an issue in the Java Management Extensions MBean (JMX) components which allowed unprivileged Java code access to restricted Java classes; this was used with a flaw in Java's Reflection API similar to the previous 0day hole from 2012 to raise privileges and execute code outside the Java Virtual machine. Adam Gowdiak of Security Explorations said in a Bugtraq posting that Oracle had not been through enough in checking for other attack vectors when they fixed the previous hole and it appears that someone found another way to leverage the Reflection API flaws which didn't run into Oracle's added security checks. "Bugs are like mushrooms, in many cases they can be found in a close proximity to those already spotted," said Gowdiak, adding: "It looks [like] Oracle either stopped the picking too early or they are still deep in the woods..."
Users can check whether Java is enabled in their browser by visiting The H's Browsercheck.
Apple updated its XProtect configuration for Mac OS X users by setting the value for the minimum version of Java to be allowed to run to an as yet unreleased version 1.7.10.19. This has the effect of blocking Java in the browser with a "blocked plugin" message, though clicking on the plugin suggests going to Oracle to download an update which isn't available yet. Apple have previously published details of how to completely disable the Java plugin in Safari.
Mozilla's block is a little less effective: the company announced that it had added Java 7 update 9 and 10 and the most recent updates of Java 6 (update 37 and 38) to the list of plugins which require "Click to Play". This protects against drive-by malware, but a malicious site could still use social engineering to convince a user to start a dangerous applet. To fully disable Java, it is recommended that you use the Mozilla "How to turn off Java applets" instructions. These instructions are customized to the operating system and Firefox version users view the page with; for other operating systems and versions, readers should use the selection buttons at the top of the Mozilla article.
Google has not, at the time of writing, taken any action to automatically inhibit the Java plugin from running in its Chrome browser. Chrome users will need follow the instructions from the Google page on Plug-ins. This entails putting chrome://plugins/ in the browser address/search bar, which will display all the installed plugins, searching for Java plugin in the list and clicking on the "Disable" link.
Java 7 Update 10 did add the capability on Windows' Java Control Panel to disable Java in the web browser by deselecting "Enable Java content in the browser". This is the simplest way for Internet Explorer users to disable Java plugins; however, as US CERT points out, bugs in the Java 7 installer may mean the control panel applet is missing. The javacpl.exe applet can be launched manually and is usually found in C:\Program Files\Java\jre7\bin or C:\Program Files (x86)\Java\jre7\bin.
The vulnerability itself has now been identified as making use of an issue in the Java Management Extensions MBean (JMX) components which allowed unprivileged Java code access to restricted Java classes; this was used with a flaw in Java's Reflection API similar to the previous 0day hole from 2012 to raise privileges and execute code outside the Java Virtual machine. Adam Gowdiak of Security Explorations said in a Bugtraq posting that Oracle had not been through enough in checking for other attack vectors when they fixed the previous hole and it appears that someone found another way to leverage the Reflection API flaws which didn't run into Oracle's added security checks. "Bugs are like mushrooms, in many cases they can be found in a close proximity to those already spotted," said Gowdiak, adding: "It looks [like] Oracle either stopped the picking too early or they are still deep in the woods..."
Users can check whether Java is enabled in their browser by visiting The H's Browsercheck.
Comments
