10 ms·

New Zero Day Java Vulnerability Being Exploited in the Wild

129 points by derpenxyne 14y ago

yxhuvud 14y ago
Does this apply to server side java as well, or is it only the browser client crap that noone has used this decennium?
- spartango 14y ago
  Client-side (browser-plugin) only: Java in the browser (applets, web start) runs in a plugin which is supposed to have a strong sandbox to prevent applications from doing things like touching files or controlling your window manager without your permission. On the server (or invoked from the commandline/jar), the security policy is much looser and there's no sandboxing (outside of what the OS and interpreter prevent).
  - jiggy2011 14y ago
    Yes, although I would generally recommend running your server side Java software inside a chroot jail.
    - foohbarbaz 14y ago
      That's pretty silly. Why?
      - yuliyp 14y ago
        To be fair, running any internet-facing apps in a chroot jail is a good idea no matter which language they use.
      - jiggy2011 14y ago
        Isolation, helps to limit the damage done by a random bug or attack. Can also be useful when you have apps with weird dependencies.
- sandbags 14y ago
  I've asked the same question. I would guess the same vulnerability would be present but only exploitable if a Java app that you run somehow contains or downloads the malicious code. But any server/desktop app you run probably already has enough vectors to exploit your system.
- foohbarbaz 14y ago
  No, it does not. This is non-news. Agreed, nobody uses that anymore, nobody should.
  - freehunter 14y ago
    All the people commenting on this saying Java is never used by anybody and no one should be having it installed are way off, seriously. There's a reason Java is #2 on the TIOBE language list. Just because you never see it doesn't mean it's not being used. You might not know this, but Gmail is Java powered on the backend. Many banking sites use Java for a backend. In the corporate world, Java rules and is required to be installed on their machines.
    - foohbarbaz 14y ago
      This has nothing to do with Java. It's a browser plugin issue. Disable the plugin and forget.
      - freehunter 14y ago
        You must have missed my last sentence. People work at the companies who are running Java on the server. People work at the companies who are developing Java on the desktop. A lot of people. A significant enough number of people that the language makes #2 on the TIOBE list. Debates about the TIOBE relevancy aside, it's at least somewhat of an indicator. People are working for companies that use Java, and these employees cannot disable Java in their browser because it's required for their job. I happen to work at one of these shops, and I can confirm to you 12,000 people in the US from just my company alone who must have Java in their browser and running constantly. We're not alone in this regard. We're all vulnerable, and the suggestion to disable the plugin doesn't help much.
      - mrgoldenbrown 14y ago
        OK. I took your advice. Except I couldn't forget because now my VPN client, gotomeeting, and various internal enterprisey things all stopped working :)
  - 14y ago
- MichaelGG 14y ago
  Seems like it applies to Java, period. So yes, could affect servers. It's another sandboxing bypass. It's just unlikely that you're depending on sandboxing on servers, unless you're running some shared environment with untrusted code from third-parties. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4681 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-468... "bypasses SecurityManager restrictions by (1) using com.sun.beans.finder.ClassFinder.findClass and leveraging an exception with the forName method to access restricted classes from arbitrary packages such as sun.awt.SunToolkit, then (2) using "reflection with a trusted immediate caller" to leverage the getField method to access and modify private fields"
  - foohbarbaz 14y ago
    Sandboxing in JVM is broken. Server code does not rely on that (most of the time). Sandboxing is inherently insecure. It usually comes with appropriate warnings (ex: Python) and everybody is expected to understand that it is a half measure at best.
- mrgoldenbrown 14y ago
  Except anybody that use gotomeeting, any number of VPN applications, and any number of enterprise applications, or lives in countries whose official government web sites still use applets, etc etc etc.
mark-r 14y ago
Is there any reason to keep Java on your browser anymore? I can't remember the last time I needed it.
- jiggy2011 14y ago
  The remote KVM facilities for my VPS host requires it and some web launchable VPN systems seem to require either Java or ActiveX.
  - fuzzix 14y ago
    Ah yes, I was wondering why I kept the plugin functionality of Java around. My HP JetDirect print server also uses a small mass of applets to perform advanced functions like setting an IP or finding out if the printer is online.
- tquai 14y ago
  No, and in fact, Java should be completely uninstalled. 99/100 people never use it for anything, browser or otherwise. The small percentage that does can just reinstall it as needed, as Java is a free download. Uninstall it, completely, and the next time this article is posted (with the dates changed and little else), you'll be glad it has nothing to do with you.
  - eropple 14y ago
    I would bet that more than 1% of people who use their computers for work purposes use WebEx. Java client.
    - mark-r 14y ago
      OK, WebEx is a counter-example that I've heard of and used. Is there a version that doesn't require Java?
      - eli 14y ago
        There are definitely alternatives to WebEx, but I often have to join online conferences that I did not organize, which means I don't have a huge say in which platform is used.
benmmurphy 14y ago
Someone has posted the source code here: http://pastebin.com/raw.php?i=cUG2ayjh http://pastebin.com/raw.php?i=cUG2ayjh This is a result of two vulnerabilities one of which Oracle tried to fix in the last patch release with CVE-2012-5088. http://icedtea.classpath.org/hg/release/icedtea7-forest-2.3/jdk/rev/43113374306c http://icedtea.classpath.org/hg/release/icedtea7-forest-2.3/... https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5088 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5088
jsaxton86 14y ago
This family of JRE attacks is far too common. Basically, when an unsigned applet runs, the JRE tries really hard to prevent it from creating a ClassLoader object. However, if you manage to create a ClassLoader object, it's game over -- you can break out of the sandbox and do whatever you please. <shameless plug> For those interested, a recent blog post of mine analyzes a similar attack that uses CVE-2008-5353: http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-part-2/ http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-p... </shameless plug>
martinced 14y ago
Damn... I thought it was another remote DoS (like the semi-recent hashmap degenerating that could be triggered by using parameters in URL like aa=xx, ab=yy, ac=zz, etc. or the floating-point 12-years old bug that people noticed could be remotely triggered on any Tomcat server) and that, once again, I'd have to apply a workaround on my Java servers. Thankfully this one is only concerning Java applets. Java applets where probably the stupidest thing ever. They surely did sck and did bring terribly bad reputation to Java : ( Don't know who's still using them. Can Google Chrome even be made to run Java applets? I know latest OS X don't even ship* with Java anymore...
- tomjen3 14y ago
  The company I work for made Java applets (specifically online games) until very recently. To interact with the danish government online (say because you want to update your tax records) you have to login -- with a java applet. That also means you can't do it from your phone. Yeah, Java is still used in plenty of places, and yes Chrome still support it.
- JabavuAdams 14y ago
  Java applets were great for graphics demos and teaching apps. Flash and Unity, etc have taken over, but who's to say that they are more secure?
- taylodl 14y ago
  Exactly. A web application platform you should have stopped using 10 years ago is still causing problems. Imagine that!
- Chris_Newton 14y ago
  Java applets are still in wider use than you seem to realise. For example, in some places, they seem to be the norm for things like on-line banking or interaction with government web sites. As a second example, they are also used for UIs on network-accessible devices. As a third, I’ve seen quite a few used for interactive illustrations on academic/training web sites. People have been doing these things with Java for at least as long as they’ve been doing them with Flash. And there are plenty more cases: tomjen3 already mentioned games, IIRC the conference call/screen sharing service used by one of my clients is Java-based, etc. The likes of Google and Mozilla might want us all to drop these tried and tested technologies and move to shiny new ones like HTML5 and the latest JS and CSS developments, but realistically, it takes time for users to move on. Most of us don’t have the luxury of controlling our customers’ platforms so we can ensure they run up-to-date builds of Firefox or Chrome with all the latest toys. It takes time for developers to move on, too. I’m currently working on a project that uses a Java applet for a client. If I were starting the same project today, I’d probably chose different tools, but it wasn’t started today, and not so many years ago when the architectural decisions were being made, those new tools didn’t exist yet. The main thing holding Java applets back today seems to be the second rate support they now get from the major browsers and/or Oracle, assuming they are supported at all. The number of blatant, show-stopping bugs in browser/Java interactions is getting silly, and code that has worked for years is breaking because someone installed a software “upgrade”. That’s a pity, IMHO, because the JVM is still a decent platform, and there are several interesting modern programming languages other than Java itself that we could be using to develop web apps otherwise.
xSwag 14y ago
The exploit has already made it to exploit packs: http://krebsonsecurity.com/2013/01/zero-day-java-exploit-debuts-in-crimeware/[1] http://krebsonsecurity.com/2013/01/zero-day-java-exploit-deb...
tomjen3 14y ago
If this is known, why hasn't Sun fixed the issue?
- freehunter 14y ago
  Wondering why Oracle hasn't patched a vulnerability is an exercise in frustration. You pretty much have to expect that if you're running Java, you're running a insecure program that will never be secured. Historically, by the time Oracle has patched the current flaw, there will be a couple more they haven't patched again.
  - yuhong 14y ago
    Would Oracle patching Java monthly instead of quarterly help?
- benmmurphy 14y ago
  Oracle have three month patch cycle.
  - tomjen3 14y ago
    Surely not for critical issues like this?
    - benmmurphy 14y ago
      it is highly likely they knew about the issue before the zero day. if they are aware of an issue but it is not public they will patch it within the 3 month cycle. if it becomes public then they are forced to patch it.
      - kleiba 14y ago
        Why is it highly likely, you think?
- ExpiredLink 14y ago
  Sun?
benmmurphy 14y ago
Metasploit module has been made available: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/java_jre17_jmxbean.rb https://github.com/rapid7/metasploit-framework/blob/master/m...
rundmc 14y ago
http://superuser.com/questions/201613/disable-java-plugin-in-google-chrome http://superuser.com/questions/201613/disable-java-plugin-in...
anuraj 14y ago
How many use Java applets still? It is high time browser plugins for Java are killed. But the article advises to uninstall Java, not understanding Java browser plugin is different from Java.
drivebyacct2 14y ago
Please, please, please turn on Click-to-Enable in your browser. You'll appreciate it even if not for the security benefits. http://howto.cnet.com/8301-11310_39-57536917-285/enable-click-to-play-for-chrome-plug-ins/ http://howto.cnet.com/8301-11310_39-57536917-285/enable-clic...
ccdan 14y ago
Nonsense... I have never heard of anyone being attacked in any way through java... it's just "security" firms that come up with all kinds of obscure things and try to scare people for pretty much nothing...
jmitcheson 14y ago
If anyone's interested in how the exploit works, here is my humble interpretation of the pastebin link: jsaxton86's comment sets the scene nicely so I'll just copy it here: "This family of JRE attacks is far too common. Basically, when an unsigned applet runs, the JRE tries really hard to prevent it from creating a ClassLoader object. However, if you manage to create a ClassLoader object, it's game over -- you can break out of the sandbox and do whatever you please." The exploit is very clever, it never actually creates an instance of the ClassLoader object, but rather it uses Java reflection to call a particular method on a ClassLoader object, which was tricked into creation inside a separate exploit involving the JMX (Java Management Extensions) framework. JMX has its own methods to instantiate classes, and a subclass of ClassLoader ("sun.org.mozilla.javascript.internal.GeneratedClassLoader") is passed in as a String; then the method defineClass is called via reflection in a way that deceives all the ClassLoader protection. Once this method is allowed to be invoked via reflection, it's "game over" as explained at the start. http://pastebin.com/raw.php?i=cUG2ayjh http://pastebin.com/raw.php?i=cUG2ayjh http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html http://www.oracle.com/technetwork/java/javase/tech/javamanag... http://www.cs.rit.edu/usr/local/pub/swm/jdoc6/com/sun/jmx/mbeanserver/MBeanInstantiator.html http://www.cs.rit.edu/usr/local/pub/swm/jdoc6/com/sun/jmx/mb...

129 points by derpenxyne 14y ago

yxhuvud 14y ago

Does this apply to server side java as well, or is it only the browser client crap that noone has used this decennium?

spartango 14y ago
Client-side (browser-plugin) only: Java in the browser (applets, web start) runs in a plugin which is supposed to have a strong sandbox to prevent applications from doing things like touching files or controlling your window manager without your permission. On the server (or invoked from the commandline/jar), the security policy is much looser and there's no sandboxing (outside of what the OS and interpreter prevent).
- jiggy2011 14y ago
  Yes, although I would generally recommend running your server side Java software inside a chroot jail.
  - foohbarbaz 14y ago
    That's pretty silly. Why?
    - yuliyp 14y ago
      To be fair, running any internet-facing apps in a chroot jail is a good idea no matter which language they use.
    - jiggy2011 14y ago
      Isolation, helps to limit the damage done by a random bug or attack. Can also be useful when you have apps with weird dependencies.
sandbags 14y ago
I've asked the same question. I would guess the same vulnerability would be present but only exploitable if a Java app that you run somehow contains or downloads the malicious code. But any server/desktop app you run probably already has enough vectors to exploit your system.
foohbarbaz 14y ago
No, it does not. This is non-news. Agreed, nobody uses that anymore, nobody should.
- freehunter 14y ago
  All the people commenting on this saying Java is never used by anybody and no one should be having it installed are way off, seriously. There's a reason Java is #2 on the TIOBE language list. Just because you never see it doesn't mean it's not being used. You might not know this, but Gmail is Java powered on the backend. Many banking sites use Java for a backend. In the corporate world, Java rules and is required to be installed on their machines.
  - foohbarbaz 14y ago
    This has nothing to do with Java. It's a browser plugin issue. Disable the plugin and forget.
    - freehunter 14y ago
      You must have missed my last sentence. People work at the companies who are running Java on the server. People work at the companies who are developing Java on the desktop. A lot of people. A significant enough number of people that the language makes #2 on the TIOBE list. Debates about the TIOBE relevancy aside, it's at least somewhat of an indicator. People are working for companies that use Java, and these employees cannot disable Java in their browser because it's required for their job. I happen to work at one of these shops, and I can confirm to you 12,000 people in the US from just my company alone who must have Java in their browser and running constantly. We're not alone in this regard. We're all vulnerable, and the suggestion to disable the plugin doesn't help much.
    - mrgoldenbrown 14y ago
      OK. I took your advice. Except I couldn't forget because now my VPN client, gotomeeting, and various internal enterprisey things all stopped working :)
- 14y ago
MichaelGG 14y ago
Seems like it applies to Java, period. So yes, could affect servers. It's another sandboxing bypass. It's just unlikely that you're depending on sandboxing on servers, unless you're running some shared environment with untrusted code from third-parties. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4681 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-468... "bypasses SecurityManager restrictions by (1) using com.sun.beans.finder.ClassFinder.findClass and leveraging an exception with the forName method to access restricted classes from arbitrary packages such as sun.awt.SunToolkit, then (2) using "reflection with a trusted immediate caller" to leverage the getField method to access and modify private fields"
- foohbarbaz 14y ago
  Sandboxing in JVM is broken. Server code does not rely on that (most of the time). Sandboxing is inherently insecure. It usually comes with appropriate warnings (ex: Python) and everybody is expected to understand that it is a half measure at best.
mrgoldenbrown 14y ago
Except anybody that use gotomeeting, any number of VPN applications, and any number of enterprise applications, or lives in countries whose official government web sites still use applets, etc etc etc.

mark-r 14y ago

Is there any reason to keep Java on your browser anymore? I can't remember the last time I needed it.

jiggy2011 14y ago
The remote KVM facilities for my VPS host requires it and some web launchable VPN systems seem to require either Java or ActiveX.
- fuzzix 14y ago
  Ah yes, I was wondering why I kept the plugin functionality of Java around. My HP JetDirect print server also uses a small mass of applets to perform advanced functions like setting an IP or finding out if the printer is online.
tquai 14y ago
No, and in fact, Java should be completely uninstalled. 99/100 people never use it for anything, browser or otherwise. The small percentage that does can just reinstall it as needed, as Java is a free download. Uninstall it, completely, and the next time this article is posted (with the dates changed and little else), you'll be glad it has nothing to do with you.
- eropple 14y ago
  I would bet that more than 1% of people who use their computers for work purposes use WebEx. Java client.
  - mark-r 14y ago
    OK, WebEx is a counter-example that I've heard of and used. Is there a version that doesn't require Java?
    - eli 14y ago
      There are definitely alternatives to WebEx, but I often have to join online conferences that I did not organize, which means I don't have a huge say in which platform is used.

benmmurphy 14y ago

Someone has posted the source code here: http://pastebin.com/raw.php?i=cUG2ayjh http://pastebin.com/raw.php?i=cUG2ayjh This is a result of two vulnerabilities one of which Oracle tried to fix in the last patch release with CVE-2012-5088. http://icedtea.classpath.org/hg/release/icedtea7-forest-2.3/jdk/rev/43113374306c http://icedtea.classpath.org/hg/release/icedtea7-forest-2.3/... https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5088 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5088

jsaxton86 14y ago

This family of JRE attacks is far too common. Basically, when an unsigned applet runs, the JRE tries really hard to prevent it from creating a ClassLoader object. However, if you manage to create a ClassLoader object, it's game over -- you can break out of the sandbox and do whatever you please. <shameless plug> For those interested, a recent blog post of mine analyzes a similar attack that uses CVE-2008-5353: http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-part-2/ http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-p... </shameless plug>

martinced 14y ago

Damn... I thought it was another remote DoS (like the semi-recent hashmap degenerating that could be triggered by using parameters in URL like aa=xx, ab=yy, ac=zz, etc. or the floating-point 12-years old bug that people noticed could be remotely triggered on any Tomcat server) and that, once again, I'd have to apply a workaround on my Java servers. Thankfully this one is only concerning Java applets. Java applets where probably the stupidest thing ever. They surely did sck and did bring terribly bad reputation to Java : ( Don't know who's still using them. Can Google Chrome even be made to run Java applets? I know latest OS X don't even ship* with Java anymore...

tomjen3 14y ago
The company I work for made Java applets (specifically online games) until very recently. To interact with the danish government online (say because you want to update your tax records) you have to login -- with a java applet. That also means you can't do it from your phone. Yeah, Java is still used in plenty of places, and yes Chrome still support it.
JabavuAdams 14y ago
Java applets were great for graphics demos and teaching apps. Flash and Unity, etc have taken over, but who's to say that they are more secure?
taylodl 14y ago
Exactly. A web application platform you should have stopped using 10 years ago is still causing problems. Imagine that!
Chris_Newton 14y ago
Java applets are still in wider use than you seem to realise. For example, in some places, they seem to be the norm for things like on-line banking or interaction with government web sites. As a second example, they are also used for UIs on network-accessible devices. As a third, I’ve seen quite a few used for interactive illustrations on academic/training web sites. People have been doing these things with Java for at least as long as they’ve been doing them with Flash. And there are plenty more cases: tomjen3 already mentioned games, IIRC the conference call/screen sharing service used by one of my clients is Java-based, etc. The likes of Google and Mozilla might want us all to drop these tried and tested technologies and move to shiny new ones like HTML5 and the latest JS and CSS developments, but realistically, it takes time for users to move on. Most of us don’t have the luxury of controlling our customers’ platforms so we can ensure they run up-to-date builds of Firefox or Chrome with all the latest toys. It takes time for developers to move on, too. I’m currently working on a project that uses a Java applet for a client. If I were starting the same project today, I’d probably chose different tools, but it wasn’t started today, and not so many years ago when the architectural decisions were being made, those new tools didn’t exist yet. The main thing holding Java applets back today seems to be the second rate support they now get from the major browsers and/or Oracle, assuming they are supported at all. The number of blatant, show-stopping bugs in browser/Java interactions is getting silly, and code that has worked for years is breaking because someone installed a software “upgrade”. That’s a pity, IMHO, because the JVM is still a decent platform, and there are several interesting modern programming languages other than Java itself that we could be using to develop web apps otherwise.

xSwag 14y ago

The exploit has already made it to exploit packs: http://krebsonsecurity.com/2013/01/zero-day-java-exploit-debuts-in-crimeware/[1] http://krebsonsecurity.com/2013/01/zero-day-java-exploit-deb...

tomjen3 14y ago

If this is known, why hasn't Sun fixed the issue?

freehunter 14y ago
Wondering why Oracle hasn't patched a vulnerability is an exercise in frustration. You pretty much have to expect that if you're running Java, you're running a insecure program that will never be secured. Historically, by the time Oracle has patched the current flaw, there will be a couple more they haven't patched again.
- yuhong 14y ago
  Would Oracle patching Java monthly instead of quarterly help?
benmmurphy 14y ago
Oracle have three month patch cycle.
- tomjen3 14y ago
  Surely not for critical issues like this?
  - benmmurphy 14y ago
    it is highly likely they knew about the issue before the zero day. if they are aware of an issue but it is not public they will patch it within the 3 month cycle. if it becomes public then they are forced to patch it.
    - kleiba 14y ago
      Why is it highly likely, you think?
ExpiredLink 14y ago
Sun?

benmmurphy 14y ago

Metasploit module has been made available: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/java_jre17_jmxbean.rb https://github.com/rapid7/metasploit-framework/blob/master/m...

rundmc 14y ago

http://superuser.com/questions/201613/disable-java-plugin-in-google-chrome http://superuser.com/questions/201613/disable-java-plugin-in...

anuraj 14y ago

How many use Java applets still? It is high time browser plugins for Java are killed. But the article advises to uninstall Java, not understanding Java browser plugin is different from Java.

drivebyacct2 14y ago

Please, please, please turn on Click-to-Enable in your browser. You'll appreciate it even if not for the security benefits. http://howto.cnet.com/8301-11310_39-57536917-285/enable-click-to-play-for-chrome-plug-ins/ http://howto.cnet.com/8301-11310_39-57536917-285/enable-clic...

ccdan 14y ago

Nonsense... I have never heard of anyone being attacked in any way through java... it's just "security" firms that come up with all kinds of obscure things and try to scare people for pretty much nothing...

jmitcheson 14y ago

If anyone's interested in how the exploit works, here is my humble interpretation of the pastebin link: jsaxton86's comment sets the scene nicely so I'll just copy it here: "This family of JRE attacks is far too common. Basically, when an unsigned applet runs, the JRE tries really hard to prevent it from creating a ClassLoader object. However, if you manage to create a ClassLoader object, it's game over -- you can break out of the sandbox and do whatever you please." The exploit is very clever, it never actually creates an instance of the ClassLoader object, but rather it uses Java reflection to call a particular method on a ClassLoader object, which was tricked into creation inside a separate exploit involving the JMX (Java Management Extensions) framework. JMX has its own methods to instantiate classes, and a subclass of ClassLoader ("sun.org.mozilla.javascript.internal.GeneratedClassLoader") is passed in as a String; then the method defineClass is called via reflection in a way that deceives all the ClassLoader protection. Once this method is allowed to be invoked via reflection, it's "game over" as explained at the start. http://pastebin.com/raw.php?i=cUG2ayjh http://pastebin.com/raw.php?i=cUG2ayjh http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html http://www.oracle.com/technetwork/java/javase/tech/javamanag... http://www.cs.rit.edu/usr/local/pub/swm/jdoc6/com/sun/jmx/mbeanserver/MBeanInstantiator.html http://www.cs.rit.edu/usr/local/pub/swm/jdoc6/com/sun/jmx/mb...