US warns on Java software as security concerns escalate

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).

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.

Ouch.. and here I thought it was just Nordea that was stuck back at the 90s. Looks like it's even worse.

Som added bonuses: The NemID password is case insensitive and has to be types in manually.

> Best advice ever.

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 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.

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...

Don't go dragging Microsoft into this - they haven't shipped anything Java-related in a long, long time.

Also, this isn't Slashdot circa 2003, "M$" is quite passé.

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.

I think you're confused, because the Java plugin has never behaved the way you describe.

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.

I asked this (more or less) a few months ago, and apparently a fair amount of the world's online banking websites still use Java.

http://news.ycombinator.com/item?id=4454036

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.

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.

Humm but the corporate drones only care about the marketing blurb, not about real security.

Case in point, the widespread use of older versions of IE

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)