US warns on Java software as security concerns escalate(nbcnews.com)
nbcnews.com
US warns on Java software as security concerns escalate
http://www.nbcnews.com/technology/technolog/us-warns-java-software-security-concerns-escalate-1B7938755
16 comments
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.
So does FireFox, if anyone's wondering. about:config -> plugins.click_to_play
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.
"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."
> 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.
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.
Dude, you're taking it too serious. It was meant to be funny. Chillax bro! :D
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.
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 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).
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).
Maybe this will be the final nail in the coffin of the java browser plugin. I can only hope...
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.
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...
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.)
#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?!
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?!
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é.
Also, this isn't Slashdot circa 2003, "M$" is quite passé.
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!
For an article obviously aimed at non-technical people, I am amazed at how not-incorrect this is.
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.
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.
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)
It's probably a browser feature, not a Java feature. Firefox also does this.
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 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
http://news.ycombinator.com/item?id=4454036
It looks like Oracle's failure to properly patch a security hole discovered in August led to the current mess.
http://thenextweb.com/insider/2013/01/11/latest-java-vulnera...
http://thenextweb.com/insider/2013/01/11/latest-java-vulnera...
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.
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.
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.
MS should put in an explicit checkbox to disable Java. Bet they'd love to do that; now they have a reason.
> "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.
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.
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.
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
Case in point, the widespread use of older versions of IE
What does this mean for sites that use Java services internally?
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)
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.