In Denmark we have a state mandated solution for electronically signing documents and communicating with the state. logging onto public services such as the IRS, child-care services, motor registration and all sorts of other stuff is done using this service. In short, if you want to deal with the government electronically in Denmark you'll have to use this solution. It's also been adopted by all Danish banks, and is the only alternative for netbanking. In other words, if you're not a luddite your only choice is to comply and use this service called NemID (EasyID)
Yes, this runs as a java plugin. And yes the company behind NemID has come out publicly and said that it shouldn't be a problem, that they don't encourage users to disable java and that everything is safe.
In other words, if your intent is malicious you can start targeting Danes with java drive-by downloads, and be fairly sure that if you hit a machine in Denmark that has the java plugin installed that machine is used for netbanking.
What's strange is that the NemID Java applet doesn't seem to really be doing anything important. It's just a login box. It takes a username/pwd, and sends it to the server. The server responds with a query for the 2nd-factor code, which you look up on your physical NemID card, type in, and it sends it to the server. If everything matches, you're authenticated. Afaict there's nothing going on here that couldn't be done by some HTML forms: the two-factor-authentication magic is done by the server and the paper NemID card (a card with 148 one-time-use challenge/response codes).
I suspect a lot of applets are similarly futile - we have a timesheet applet at work than somehow manages to be clunkier and more annoying in use than anything you could knock up in plain HTML plus a bit of JavaScript.
Chrome has a setting to only run plugins with the user's permission. I'd advise it for anyone even remotely skilled enough to use it. I work for with quite a few java applets. Everything I need still works and the bullshit walks.
I'm wondering, why hasn't Firefox put the setting on as default. Of course it would be quite annoying with the Flash-plugin but I think it's worth the trouble.
"For versions of Java older than Java 7 (which you shouldn't be running anyway), the de-Javafication process for Internet Explorer involves editing the Windows Registry," he notes. "If you don't know what that is, don't do it. Instead, stop using Internet Explorer entirely."
I am not sure how you can construed that as THE best advice given the nature of the vulnerability being independent of the browser or the o/s in use. It maybe a good advice but not the best. Something closer to best would be disabling or uninstalling Java plugin regardless of what operating system or browser you use.
The interesting thing about that first bit, is that on recent versions of OSX, when using Chrome, you have to use Java 6. Java 7 is 64 bit only, and Chrome on OSX is only 32 bit. So you can't use a Java7 plugin in Chrome.
From what I can gather, progress on a 64 bit OSX build of Chrome has stalled.
And Norway decided to authenticate people using java applets for government sites and a separate, but similar, system for online banking. This was quite a number of years ago, but it still being rolled out on new sites today.
And their Java applet stops password managers such as LastPass, 1Password etc from working, and you cannot even copy/paste into its input fields.
I have nothing against Java or the JVM, but applets that require "full access" to your computer just to sign you in is pretty backwards. To be honest, I don't trust their code to behave on my computer, but if I don't give their applet full access, I cannot use my bank online..
I have no idea why they decided to go this route, and why it's not just a 5 minute javascript job to actually fix it.
I don't know how often you need to connect to your online bank : I do it once per week or so...
You could boot a Live Linux CD / DVD / memory stick. Either a Live Linux CD / DVD which already has Java or add it yourself to the Live CD or keep the Java install file on a memory stick. Java can be installed without being root on Linux, which is great and the installation process, once you have the install file, is very very fast (a few seconds). You could then connect to your bank's website (and only to that one) and be quite safe.
Of course it's not for the faint of hearth...
But that way you don't need to trust their code to behave well: you're basically booting a read-only Live CD with zero information about you on it. And you don't have to fear Java applets exploits from other sites (because you use that Live CD to go only to your bank's website).
I access my online bank from a Live Linux distro (Java applets aren't needed here but the principle is the same: by booting from a "read-only OS" and which I use only for online banking, the risk of being pirated are pretty small).
Another stupid scare... most idiots will blame the entire set of Java products, even though applets are just a very minor feat, almost a deprecated one... and the real threat is greatly exaggerated... there was never a major security incident in the entire history of java...
Unfortunately, the only thing standard users are going to remember is "Java is bad". I've already had friends asking me about this and saying, "isn't it going to ruin my entire online experience to disable Java?". "No, that's JavaScript, different thing entirely."
And that's from people who work with computers all day as their main job. Looks like it may be difficult/impossible to get people to install Java client apps in future.
Back in the early applet days a lot of people were complaining on Usenet's comp.lang.java.programmer that applets were both a toy and a disaster waiting to happen that would never bring anything good to Java.
Yet countless Java programmers fought teeth and nails to defend Applets, saying how great the techno was and how it was going to revolutionize the Web, etc.
They are the very programmers who, today, say that Java is good but that Java applets weren't maybe that great after all. It's a bit too easy.
Now I don't know what you call a "major security incident" but in 2011 you could DoS any Java webserver by crafting an URL (hashtable exploit). A single customer Internet connection was sufficient to take down entire Java server farms.
Granted a DoS is not remote-root but still...
Then, still in 2011, there was the 12-years old floating-point parsing bug where you could DoS any Java web server, again, by sending a thread into an infinite loop. All that was needed was one parameter set to a certain value on the client side and make your HTML GET and that's it: one thread into infinite loop.
Repeat a few times and you had DoS any Java webserver.
It's still not remote root but that's not exactly not major either...
Java Applets had great promise. Early interest was high. For the life of me, I can't phantom how Sun managed to biff this one. I'm among the biggest Java fans, so my disappointment is acute.
#1 - Netscape. Their Java support always sucked. Broken thread implementation. The joke was write once debug everywhere. The early troubles soured most and Sun lost the precious mindshare. Relying on a third party for the success of Java was a huge mistake.
#2 - Sun killed their HotJava web browser, written in Java. It was the ideal applet platform. Ran great. Had a great UI for the time. Imagine if they'd kept that going.
#3 - Sun waited until Java 6, a full decade, to revamp their Java plugin. Way too late to make a difference.
#4 - AWT controls looked terrible, were too minimal. But Swing was just too heavy. The design was great for time, being the logical successor to NextStep -> Cocoa -> Netscape IFC development line. But Sun never put it on a diet, either the API or the payload.
(Thanks for the floating point parse bug tip. Writing a web server using Netty, that's a good one to know.)
...jeez ...shouldn't "enterprise grade software" imply at least a "give some fuck" attitude towards security? wtf is wrong with Oracle?!
Most browsers have an autoupdate mechanism. Can't Oracle encourage browser devs to push an update with a patched java plugin and Microsoft to push a windows update with it? I mean, really, wtf?!
Ok, ok, I edited the acronym... I was thinking about updating the IE's Java plugin, and I don't know if it can be done other way than via Windows Update. I'm so annoyed by the state of Java in the browser because applets are the only means of running Clojure or Jython or JRuby or your other fav JVM language in the browser, modifying the DOM and doing whatever you wish without needing to compile to Javascript. I know, this way of doing things will die out, but today it can still be done for something like a company internal app and it's really cool from the developer's pov!
I was under the impression that Java still prompts the user to allow applets to start before they're even called - is this still true, or am I missing something? The dialog always advises not running applets from places you don't trust, last I checked.
This doesn't mean much to most users, like my parents.
There's a generation of computer users who were dragged into the technology. Sure, now they may or may not love it, but throughout that time they were conditioned to just click 'OK' if it got in the way of whatever they were trying to do.
This isn't an exploit targeted towards the security experts, much less people who know what "not running applets from places you don't trust" even means.
For signed applets which get full privileges anyway, yes, Java will prompt you to accept the certificate. However, Java does not prompt before running unsigned applets (which run with limited privileges), and the actual security issue allows unsigned applets to gain more privileges than they should have. So, unfortunately, the prompt doesn't help.
All of the sites with Applets I go to do this in Chrome on OSX (unless I've explicitly said the site is trusted after the first time I run it) (Can't recall a site off the top of my head, else I'd post a screenshot)
That's the browser, not the plugin. We added it to Chrome a few years ago for out-of-date plugins, and plugins that have a bad track record on fixing their vulnerabilities (e.g. Java). Firefox recently added the same thing for out-of-date plugins, and just this week started doing it for all versions of Java.
Are Java applets still used anywhere? I haven't seen them in open web in years (I see one in my companies reporting software made by third party - no one knows why it requires java to do it's things)
It's astonishing how often one still sees Java in device configuration web pages, ie. printers, PBX systems. It's also still used for weird hardware devices that are deployed in a lot of financial services, like signature pads. Lastly, vertical applications that don't recieve a lot of updates.
It's almost impossible to understand why java is necessary in most of these applications, but simply removing the plugin from a lot of corporate environments would disrupt vital business functions.
It's my perception that Java is plagued with more frequent security problems than Flash, and Flash moreso than Javascript.
Is this perception accurate?
If so, what's the reasoning? I would think Javascript would be the most-breached browser-based code execution sandbox for the same reason Windows is the most-breached OS: It's the most popular.
For one thing, there's no code base called "JavaScript." There's V8, SpiderMonkey, JavaScriptCore, Chakra, and more, and an exploit in one is unlikely to work in others. Flash and Java each have a larger market share than any given JavaScript implementation.
Java is an interesting case in that the same platform needs to support sandboxed browser applets and desktop/server software. Unlike JavaScript, the designers of Java don't have the ability to simply leave the capability of OS access out of the platform entirely. They rely on a sandbox to keep untrusted code from calling unsafe procedures, and it's the sandbox that failed here.
the DOM doesnt allow most of the things an applet can do , furthermore security lies in browser , not a third party plugin. A plugin is a native extension running directly in the user machine , javascript and the DOM api run only in the browser ( in the client context ). Doesnt mean javascript is secure , it means the browser vendors directly are responsible for its security.That's not the case with a plugin.
I get so tired of articles confusing running Java on a server and running Java on a web browser via a plugin. The latter is dangerous the former is not. But this is rarely made clear when people write about it.
> "To defend against this and future Java vulnerabilities, disable Java in Web browsers."
That's not the problem. Attackers can execute Java code through other attack vectors (JavaScript, Flash? PDF?). The only solution seems not having java on your search path. Open a command window, type 'java' (without quotes). If you can call java that way you are vulnerable.
If an attacker can execute code through other attack vectors (JavaScript, Flash, or whatever), and happens to execute Java, instead of say native code, or batch files, or something else, that's not a problem with Java, it's a problem with those programs that have the vulnerability.
The only way to be safe is to take your computer, encase it in a brick of cement, and drop it in the Mariana Trench. NoScript and careful browsing habits go a long way, though.
What developpers dont understand is that it hurts the brand. if Java is associated with malwares and exploits , it doesnt matter how you use it , your potiental clients already heard java is bad , Oracle should either drop the plugin or get serious at fixing it.
It's related to the Java Plugin (AKA Java Applets), running in the browser, so anyone running a Java (or any JVM based language) on the server, is not related to this specific exploit.
As quoted:
> "To defend against this and future Java vulnerabilities, disable Java in Web browsers."
There are so many JVM based services out there (Including from Google, Twitter, Foursquare and many others, even many Ruby on Rails apps running on JRuby) that if it was also a server side exploit of that level, it would have been even a bigger concern. (Users getting their bank account stolen is terrible, bank get hacked is a different level of terrible)
Yes, this runs as a java plugin. And yes the company behind NemID has come out publicly and said that it shouldn't be a problem, that they don't encourage users to disable java and that everything is safe.
In other words, if your intent is malicious you can start targeting Danes with java drive-by downloads, and be fairly sure that if you hit a machine in Denmark that has the java plugin installed that machine is used for netbanking.
It's a disaster waiting to happen.