New Java 0-day exploit spotted in the wild. | Hacker News Reader

New Java 0-day exploit spotted in the wild.

blog.fireeye.com

122 pointsgrncdr68 comments

Both Firefox and Chrome have features that disable plugins but still allow you to run individual applets on demand. Please turn these on; it's not much hassle and you'll be shutting down the most common targets for exploits.

For Chrome, go to advanced settings -> Privacy -> Content settings -> Plug-ins and select "click to play". For Firefox, go to about:config and enable "plugins.click_to_play".

Awesome, I had Click2Flash installed on Chrome, but no idea it basically already came built into the browser.

Is clickjacking a solved problem or will this only raise the bar a little?

I would go one step further and recommend that you uninstall Java thus removing one attack vector. I did so a couple of months ago and have yet to find a case where I really needed Java.

I use netbeans for php coding mostly for its code completion and use ElasticSearch for some sites I build. There's two.

Do you also equate PC with Windows?

To eliminate further attack vectors, uninstall both the browser and the OS ; ).

I just want to point out that's there's a big difference between having an interpreter on your machine like python, ruby, or java, and having a browser plugin that executes remote code by default.

There's nothing wrong with the former, there's everything wrong with the latter.

Do you mean Java in the browser? If so, what do you think is happening when your JavaScript code hits your server's REST code returning JSON?

The primary difference is that JSON isn't considered executable-- at least not by any Java JSON libraries that I've seen; it's just data.

(Yes, non-executable data can still deliver a malicious payload, e.g. http://technet.microsoft.com/en-us/security/bulletin/ms04-02.... It's just much less common-- presumably because it's a much smaller attack surface.)

you forget the time when json was usually called with exec...

But mostly it is buffer overflow bugs that get you now.

what do you think is happening? Browsers don't use Java to parse/encode JSON... JSON is a Javascript facility.

For firefox I use quickjava which puts a disable button in the bar. I can't remember the last time I actually enabled it. I do use Java quite frequently but rarely in the browser.

And drop flash too while you're at it!

Flash has legitimate uses for streaming video. I very, very rarely use Java applets.

Not that the parent was suggesting the following, but do note that if you only disable the Java browser plugins, when you next update Java (the SE package/installer, at least), the updated versions of those plugins will be installed and enabled in all or most browsers. You have to go and manually disable them, again.

I keep Java around for some other reasons, so when I update, I have to remember to go and disable the browser plugins once again.

Opera, too.

I had to go back to enabling plug-ins with Chrome, though, as I couldn't load videos for some reason.

In Opera you can so easily enable those things on a per-site basis, it is wonderful. Rightclick on page -> Site Preferences -> Content

The sad thing is that Click To Play still breaks websites. I think SoundCloud (Flash) was the one where I gave up last time. I use Safari for day-to-day browsing now and open Chrome when I need to use anything infective (Java, Flash, Facebook, Google, ...).

Click To Play breaks whenever a 1px Flash embed is used - you can't click what you can't see. I generally whitelist sites I trust (YouTube, Vimeo, Google Maps, ETrade etc.) and never have to click on Flash from those sites. Other sites show me Click To Play and 90% of the time, it's ads I want to ignore or the single video link I want to click.

There's an icon in the address bar that you can click to enable all plugins on the page, even 1px ones.

That icon doesn't appear on all sites. Sometimes it seems like the site does feature detection, comes to the conclusion you don't have flash, and refuses to serve anything useful.

Also on OS X the Flash mouse capture is broken if you enable click to play in Firefox.

Luckily, SoundCloud's next release will be HTML5-audio-only. You can also enable experimental HTML5 playback support with the current version in your settings.

Your point is correct, though. There are a lot of sites that break if they don't detect Flash right at page load.

I'll take this opportunity to recommend that anyone who is in security should think about going to work at FireEye. Ridiculously cool technology, and they routinely lead Botnet takedowns to boot, e.g.

http://www.fireeye.com/news-events/press-releases/read/firee...

Email me at the email in my profile if you would like a warm intro.

Disclaimer: my brother is a long-time engineer.

It's interesting that so many consumers (read: not java developers) have Java installed at all.

I code in Java for work and so it's on those boxes, but I have never found a need for it at home. I've only rarely come across a website that requires it.

(The only exception is ADOM2, but that doesn't require a browser plugin, you just download it like any other executable [that you trust])

Does anyone here write consumer-focused non-server Java software?

A lot of online meeting/sharing/video conf sites seem to require Java. That's the largest reason I'm aware of.

I'm using http://www.gokgs.com a lot. Its a Client for the boardgame GO.

The 3-D Secure VISA system in Norway is based on BankID (https://www.bankid.no/Dette-er-BankID/BankID-in-English) and uses Java. Everyone with a computer and a bank account has the Java plugin installed. Internationally, the majority of oekaki (online painting board) software has traditionally used Java because of its speed and versatility. My own real-time collaboration software, Sketcher, requires Java 1.5 at minimum. The software does bit-banging and custom pixel-level rendering and image compression in tight loops that can't be done fast or well enough in HTML5 or even Flash, and wasn't even possible back in 2004 when the software was originally developed. The Java code isn't as fast as native code, but it's pretty close, with Photoshop type pressure sensitive brushes rendered in real-time.

I've been looking at WebGL, but the technology isn't really ready for a mass market yet, and is widely criticized for the security holes it potentially introduces by exposing the OpenGL API to the DOM.

The whole web community seems to be ignoring rich content rendered on the client side. Without these capabilities, we'll never have real web app versions of programs like Photoshop.

Right now, my focus is on getting Kickstarter funding and developing a more user friendly version of my app for iOS, where such facilities are available today.

Minecraft

Mars Space Simulator

Yes, absolutely.

I think Java on the desktop is seriously underrated.

I've been writing Java for a desktop accounting app [1] for the last 8 years and it is fast, cross-platform, and indistinguishable from native applications.

The trick is to use SWT for the UI rather than the built-in Swing UI. SWT is lightweight, has a simple API and provides an excellent user experience. Swing is bloated, has a frustratingly-complicated API and for the most part provides a woeful user experience.

I really believe that if Sun had chosen to base their UI framework on something like SWT then today Java would dominate the desktop as much as it dominates server development. If you're curious, here's a juicy story about how the politics between Sun and IBM caused them to make such a bad choice: http://www.mail-archive.com/jug-discussion@tucson-jug.org/ms...

[1] http://www.solaraccounts.co.uk

Java on the desktop could be (have been?) great, but Sun screwed the pooch on adding the details that a good Java desktop experience needed. The Swing/SWT thing aside, they were slow to, or never did, ship support for various popular audio/video codecs, system tray integration, support for various IO channels (serial ports back in the old days, later USB, Bluetooth, etc.) and probably a whole laundry list of other things I'm forgetting.

It's sad too, because I'd still much prefer to push Java for certain classes of solutions, and still - to this day - find audio/video support (among other things) lagging.

I guess, once Java took off as a server side platform, Sun just didn't have the vision or courage to seriously push Java on the desktop. Sad. :-(

>> to this day - find audio/video support (among other things) lagging

So somehow the small gang at Mojang pulled off the impossible with Minecraft? Or the excellent apps NASA used to make with Java before the past 3 years or so like WorldWind? Or FusionCharts? or IBM Symphony, or OpenOffice, or SameTime, or HP Virtual Rooms (the last few heavy, heavy media), Apache Directory Studio, Eclipse, NetBeans, soapUI, SQL Developer?

Minecraft pegs the CPU at 100% on a C2D.

Not Java's fault I presume.

Just an an anecdote, Minecraft refuses to play audio on my desktop because the sound card is not supported, and cannot host a server because the network card is not supported. This is an off-the-shelf Asus desktop.

Looking through their forums, this is relatively common.

So somehow the small gang at Mojang pulled off the impossible with Minecraft? Or the excellent apps NASA used to make with Java before the past 3 years or so like WorldWind? Or FusionCharts?

I said "lagging", not non-existent. And clearly individuals can add support for things that aren't part of the JDK, using various OSS libraries, JNI, custom code, whatever. The point is, the lack of up-to-date, high-quality support for audio and video formats is a major detriment to "java on the desktop" for a wide range of applications.

Apache Directory Studio, Eclipse, NetBeans, soapUI, SQL Developer?

What do any of these things have to do with needing audio/video support?

Java desktop apps are just fine for about 99% of business apps - get some records from the database, make some changes, and store them. But yeah, I wouldn't use it for external customers.

Of course, where I work we're replacing pretty nice swing apps with far-less-nice web stuff. Why? Because the CTO read some trade mag that said nobody is doing fat clients anymore. Glad to see he's earning his salary. Sigh.

I write Android apps (in Java), which is consumer-focused, non-server. But the target isn't exactly desktops either.

Android devices run Dalvik, not JVM. Does stuff like this issue affect Android?

CrashPlan. Admittedly I'm more of a developer, but I have installed it on a few consumer PCs to use them as a source and sink of backups.

> It's interesting that so many consumers (read: not java developers) have Java installed at all.

Vuze (former Azureus) has quite large base install. There alose should be quite a lot of Swing in-house apps.

For the same audience (copyists) JDownloader has a huge install base as well.

In Denmark all government and financial interactions are accessed through a SSO (Digital Signatur) which is based on in browser Java applets.

A lot of government service interaction is being forced online, to reduce spending. So you are forced to at least have one Java capable browser available.

All these Java exploits --both client and server-side-- are really bad. I'm (mostly) a Java dev and I'm really sad at all this (probably deserved) bad rep Java is getting.

I run Java on Linux and my setup is simple: I install Java in my "dev" account from the .tar.gz. There's no way I'll ever ever login as "root" to install Java on a Linux machine and there's no way Java ever gets installed in something else than my "dev" user account. I surf the net from another account which, of course, has no Java installed.

I also admin two Java webapp servers and closely follow all the security issues: had to patch them twice "recently". First the DoS SNAFU related to predictable hashmap hashes where anyone could remotely DoS any Java webapp server (quite bad) and then the "infinite looping" when parsing I don't remember which HTTP header triggering a bug in floating-point code. Both bugs where known since more than ten years and Sun/Oracle never acted.

It's really a quite sad state of affair.

I've become rabidly anti-Java. My friend installed Java on my computer as part of the process of rooting my HP touchpad to install android, and within days my antivirus had detected multiple java-based attacks on my system. These were literally the first attacks since I'd wiped my HD after a previous Java related attack. I uninstalled Java immediately, and hope that I never have to install it again.

I am not a fan of the Java stack either, and for the most part am successful at keeping it away from my daily work. It is a shame too, as there are some really useful things out there that were build on Java (the ones I care about run on the server).

That said, there is a jenkins box running at $dayjob that of course requires Java. However, if I had a choice between jenkins and jenkins-clone-built-with-something-else, all things being equal I would choose jenkins-clone-built-with-something-else.

> if I had a choice between jenkins and jenkins-clone-built-with-something-else, all things being equal I would choose jenkins-clone-built-with-something-else

What on earth for? It's not as if the Java binaries on a (non-multi-user) server somehow make it less secure.

Even if it is multiuser, they're not installed with any special privileges. You can install java in your home directory.

I can't wait for the day when people get their wish, and 50% of the installed browser base will run random python scripts off the web.

There is a certain amount of Java stuff I have running at $work as well, and the one I really care the least about is Jenkins, at least it isn't executing random code from the web.

The one that has me worried way more is all of the Android build tools. I've had random crashes happen in them and there is no good way to debug the issue. Java throws stack traces that if printed would cost you a ream or two of paper and sometimes you get crashes in something completely unrelated.

Ugh, there are many things I wish for, but Java no longer existing is probably one of my biggest wishes.

Is it the JVM throwing incomprehensible stack traces?

Or is it the android SDK throwing slightly less but still uselss stack traces?

I often see the later, which is just poor error/exception handling by the developers. I very rarely (sometimes, but not enough to get annoyed) see the JVM printing out stack traces.

A stack trace is a stack trace in any language. It's the app developer's responsibility to provide a useful error messages after catching an exception.

This is CS 101, GiGo

Not all exceptions are caught, and not all caught exceptions can have useful error messages. Try to figure out the cause of an SQLException in code and you will quickly realize it is an exercise in futility. To top it off, you are at the mercy of the implementer, who often seems to choose the most cryptic message possible.

Sometimes, all you have is a stack trace.

No offence but if you don't understand how stack traces work and why it isn't a "Java" wide problem then no offence but you really are in no position to comment.

It really isn't that hard to understand.

Just because you can read the stack trace does not mean it isn't a chore.

I and everyone I know runs Java apps and on the server and on smart phone along with hundreds of millions of other people in the world and we all get along fine.

Asking out of genuine curiosity about the semantics, not being a grammar troll. Is New 0-day exploit redundant? Are all 0-day exploits new?

AFAIK a 0-day exploit is an exploit that was found in the wild. No one previously knew about it and there's a scramble to fix it.

In a week this exploit will be an "old 0-day exploit" because the "0-day" bit describes developer preparedness at discovery, not how long the exploit has been known.

"n-day" refers to the number of days since a fix was released. So a vulnerability can be "0-day" indefinitely if the software maker never patches it - and in those circumstances it would make sense to talk about an "old 0-day".

Fireeye needs to learn how the censor IPs. From the screen shot I could tell it was 59.120.154.62.

I wish they wouldn't censor it at all. Working in network/information security, when I see one of these posts the first thing I do is go into our SIM tool and look to see if any of our clients have been seen talking to this address. I then do a reverse-DNS lookup to find the domain name they have censored to see if our DNS has been talking there. Censoring it just makes my job harder, and defeats the point of the entire blog post.

Ah well. Somebody already has obtained the sample from the url for us. Most likely bruteforced the address.

http://twitter.com/jduck1337/status/239875285913317376

Reverse-DNS'ing the IP address gave me the URL they mentioned and censored in the article. I didn't want to post it here on HN because this isn't the place for that. I would think FireEye's blog would be that place. I'll have to get with my FireEye sales engineer to see why they censor there.

How did you find the domain through reverse dns? None of the queries I ran gave any useful results.

I use robtex.com to reverse-DNS [1]. It tells you if the address is listed in any blacklists, what domains are registered there, who owns the network, and where the geographical region of the server is. Listed in the registered domains is something awfully similar to what FireEye has censored out.

[1] http://www.robtex.com/ip/59.120.154.62.html#ip

In case anybody at FireEye reads this: is Windows XP the only OS vulnerable to this attack?

I'm not from FireEye, but XP is not the only OS vulnerable. Rapid7 has created an exploit for Metasploit and was able to successfully execute an attack against a fully patched Windows 7 SP1 with Java 7 Update 6.

http://www.securityweek.com/new-java-exploit-spotted-wild

In addition to 7 which was already mentioned, Rapid7 says they've successfully tested it against Ubuntu 10.04 and OSX 10.7.4 as well.

https://community.rapid7.com/community/metasploit/blog/2012/...

Errata Sec claims it's working on a fully-patched Ubuntu 12.04, provided you're using the official Java package instead of the default OpenJRE. OSX 10.8.1 has also been confirmed.

http://erratasec.blogspot.com/2012/08/new-java-0day.html

The exploit (applet.jar) contains two classes - Gondzz (dropper downloader) and Gondvv (the exploit). Here is the decompiled source code of Gondvv: http://pastie.org/4594319

Reply on news.ycombinator.com