Sophos Cloud Optix
After two decades of awful memories and zero-day vulnerabilities, Oracle is killing off the notoriously insecure Java browser plug-in. When Oracle releases version 9 of the Java Development Kit (currently anticipated for 23 March 2017), it’ll be deprecated and gone.
For those too young (or too traumatized) to remember, there was a moment way back in the 1990s when “Java in the browser” looked poised for global domination. Sun Microsystems’ tiny animated Duke applet seemed the harbinger of the web’s animated, cross-platform future.
Thundering herds of developers built thousands of applications designed to run on Java through a browser plug-in. Not just junky animations: business applications of all kinds.
Thanks to the cross-platform NPAPI plug-in API standard, Java plug-ins and their applications could run on multiple browsers, on multiple platforms – generating colossal security holes and killer migraines for anyone who cared about the safety of their computing environments.
First Sun – and then its successor Oracle – invested massive time and effort in shoring up Java browser security. But Java’s vulnerabilities kept on coming. Take for example:
- The massive bestiary of Java applet security flaws cataloged years ago in Securing Java.
- The newer Java flaws embedded in the Blackhole exploit kit in 2012.
- The multiple Java flaws CERT told the world about in 2013 – flaws that affected Java inside and outside the browser, with “web browsers using the Java plug-in… at particularly high risk”.
With each new security nightmare, we (and plenty of other experts) told everyone to get rid of Java in the browser. Gradually, most folks listened. Those responsible for fast-growing mobile platforms like iOS and Android never let Java plug-ins near their browsers.
Finally, in 2015, leading desktop browser makers – Google, Mozilla and Microsoft – all announced plans to stop supporting the NPAPI standard that made them practical. It’s becoming increasingly difficult to run Java in a halfway modern PC browser, should you so desire.
OK, nobody “so desires.” But some folks are still forced to run it, by legacy applications that still haven’t been upgraded or replaced.
Some of that software was built in-house many years ago, and somebody somewhere in management can’t bring themselves to pay for replacing it. (Please: bite the bullet.)
Some folks are still running vertical market applications dating to the Pleistocene. So says BeyondTrust executive Morey Haber in TechTarget’s SearchSecurity, “many financial and healthcare applications [are] pure Java and will have to adapt… legacy applications for professionals like radiologists or financial planners will require older browsers, continue to be vulnerable, and represent an exponential risk”.
Occasionally, even a major enterprise system shows up on the list – for example, in TechNewsWorld, Bromium CTO Simon Crosby cites Oracle ERP 11 as still requiring the flawed Java 6 or 7 at the endpoint.
If you’re still stuck with an application that requires Java in the browser, you (or your vendors) have two primary migration options. You can use the modern standards-based HTML5 to deliver comparable functionality in modern browsers, without Java. Or you can convert your Java code with Oracle’s Java Web Start technology.
Once you’ve done that, it can be launched outside the browser from either a desktop shortcut or a web link. If the latter option interests you, check out Oracle’s brief white paper on Java Web Start, and don’t miss its tips on tracking down stray Java applets still lurking in your infrastructure.
With Oracle killing the Java plug-in, and browser-makers abandoning it in droves, this might be the last time we ever have to tell anyone to trash Java in the browser. That would be so great.
Image of Java courtesy of Gil C / Shutterstock.com
easy fix, a sand-boxed virtualized app running the specific flavor of Java you need and IE version you need… lock it down to only have access to the on app or site that you need. All other “browsing” use a modern somewhat secure browser. If any claims its too much work to switch, slap them.
I am kind of bummed. There were actually several browser Java applications that were useful(like CISCO’s firewall GUI was built in Java). In some ways, I am very glad to see it go and in other ways I am sad that NPAPI support going away is causing such a headache for developers and making many useful applications no longer viable.
You don’t actually need a browser to use Cisco’s ASDM (Firewall GUI). It has used the WebStart technology to allow it to be run natively for as long as I can remember. One problem, though, is that, depending on the version of the ASA and ASDM plugin software you are running, you may need a specific (vulnerable) version of Java.
Kill it with fire!
Great! Now, how do we get rid of Flash??
Makes me laugh that such a computer giant like Nvidia still require you to run java when they scan your pc checking for out of date drivers etc
There’s a big difference between a Java application (which is a program you download by choice and has the same sort of access to your system as software written in any other programming language) and an applet (which is pushed into yur browser and run automatically, though supposedly in a safe and limited “sandbox”).
that’s gonna leave a mark… yes, there are/were some good implementations but the security problems have always been much larger than the benefits given… especially after the hackers jumped into the fray and pointed them out… now if they can fix the rest of the problems, there might be some real headway made in securing everything…
And next, Adobe should kill Flash!
Great!!! Yay! we killled the Java sandbox on web-browsers. Now we can move on to removing insecure Java form the Android App store. Woohoo! Once Java is gone from Android mobiles can be secure too. (cause, OS controls over java processes totally isn’t a modified sandbox or anything…)