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.
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.
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.
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.
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.
By that thinking, you should completely uninstall anything that is not necessary to run Internet Explorer or Microsoft Office.
If you actually do novel things with your computer from time to time, you are likely to run into Java sooner or later. If you run the same three programs all the time, sure, ruthlessly uninstall everything else.
Even on a desktop where I am not currently using any Java apps, I see no reason to go out of my way to uninstall it if it's already there. It isn't hurting me, and installing it is enough of a pain that avoiding that hassle is a win.
If you work in a corporate environment for an employer who is proud to be a Java shop. There's more of them than you might realize, and working in the IT security field for these places can drive you up the wall.
I sometimes curse the Linode remote console because it's buggy, slow, and the list of unsupported operations could fill a library, but at least it's not Java. I didn't know Rackspace's used Java.
Linode recently replaced the AjaxTerm based web console with a Shell-in-a-box version. Also you can always access the console using SSH to the host instead of the web version.
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.
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.
"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"
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.
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.
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).
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.
Just because the Java plugin is rarely used doesn't mean it isn't installed. Most PCs I see have Java installed, whether bundled by the OEM or some third-party piece of software, and Java always installs its plugin.
Stat Owl reports that the Java plugin is installed on 68% of browsers[0] based on data from 28 million monthly uniques[1].
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.
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.
OK. I took your advice. Except I couldn't forget because now my VPN client, gotomeeting, and various internal enterprisey things all stopped working :)
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...
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.
zero day means it was first seen in the wild (ie, they just found out about it very recently as well). It takes more than a day or two for even some of the most efficient organizations to find, fix, test and deploy even a critical vulnerability, especially when said organization supports hundreds of different permutations of architecture/os/major level/minor level etc. etc. And oracle is far from the most efficient of organizations.
The reason you normally see fixes deployed when you hear about the bug is because of "responsible disclosure" - details are held until a fix is ready. Those suggesting that oracle won't fix this outside of their normal quarterly patch cycle are off the mark though, surely there will be a (relatively) quick response from them (within a week or two would be my bet).
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.
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...
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.
I've literally never seen Java in the wild that's not part of an exploit kit. I've disabled Java in every browser / OS since about 2007, and I'm yet to be unconvinced by not having it.
Can you show me any examples of what I might be missing out on?
The applet I’m working on is rather specialised, so talking about that isn’t going to prove much. Others have pointed out some common examples from among the fields I mentioned, such as Minecraft, WebEx, and Danish government web sites. Each of these has a significant user base relying on Java applets.
Does Minecraft use applets or is it just a standalone desktop Java app? Does installing Minecraft create any vulnerability to this bug on a machine whose browsers have deactivated any Java plugin?
Besides downloading the Java app, you can play Minecraft in the browser through an applet at https://minecraft.net/play.
So no, if you are not running Java in the browser, a malicious web page can't run neither Minecraft nor other Java apps that you have locally installed.
Just about every out-of-band management card (e.g. HP iLO, Dell iDRAC) for server-class computers, uses the Java plug-in to present a KVM (keyboard/video/mouse) console through a web browser.
JVM is pretty much the only platform, unless you want to be Windows-only. This however has absolutely nothing to do with Java browser plugin. The sooner that thing dies the better. Just disable the "Java plugin" in the browser and forget about it.
Currently it's the best way to serve labels for thermic printers that our clients need.
There is no direct input to the printer as a byte buffer, the browser will always print a markup document. Unless HTML5 comes up with Printer Sockets, we are stuck with Applets in order to be granted hardware access to the client machine.
The same problem applies to most point of sale hardware, the stuff we use doesn't mostly care about drivers at all. Receipt printers just want raw bytes sent to their port, no matter COM or LPT or LAN - OS is bit of an obstruction on the way. Kind of sad that web-based POS software can't take full advantage of the conveniences web brings (ease of updating the program, easier and prettier graphical designs) without losing the capability of interfacing properly with hardware.
One thing about applets is they are the only way I know of to generate UDP packets from the browser. If it wasn't for that I couldnt think of anything.
It looks like you tried to censor suck for some reason and triggered the markup between the asterisk used for censoring and the first one highlighting the word ship.
<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-p... </shameless plug>