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".
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.
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.
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.
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.
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, ...).
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.
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.
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.
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.
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?
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.
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...
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?
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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
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".