Her in Norway most banks have gone together and made a common id system known as "Bank ID" that uses Java. It is used for many online transactions, not just banking. Many can't buy things like movie tickets or online goods without using it.
Movie tickets, airline ticket, most online stores. Being Java it of course also doesn’t work on mobile phones, pads, etc.
They are starting to roll out a version for mobile phones now, but it requires that your operator supports it and many will need a new sim card so it takes time.
In the meantime if you are out with your friend and you finds out you want to see a movie, you will have to walk to the theater or call a friend with a pc to buy a ticket. You can't just do it online from you iPhone (some movie theaters may have a app for that, but not where I currently live :( ).
It feels especially bad because it wasn't always like this. Before the massive adoption of Bank ID you could do almost anything online from your phone.
Do you mean the Java browser plugin? If so, I agree with you, but this is still a serious issue even if you just have Java installed for desktop applications.
EDIT: To elaborate on jokc's reply (who appears to be shadowbanned), it seems that this exploit is only a problem for applications that use Java's sandboxing features, and the browser plugin is the best example of this -- but desktop applications can use these features too.
If they aren't sandboxes you don't need the vulnerability. Then the only question is if you can run untrusted code. Which is going to depend on the application.
If you're downloading an application and running it, it's pretty much immaterial whether it's Java-based or not; there's no vulnerability required to trash your computer at that point.
Sandboxes only apply in the browser, as far as I can think of -- Java code all executes in the context of a security manager, but does anyone actually set a custom security manager for running untrusted Java applications? (Maybe I'm just missing an example you know of...)
I like how "I don't use it" converts so easily into "no one uses it".
I'm afraid people do use it; of course the banks and so on (who probably can migrate to better solutions fairly easily); personally, I have a site that's pretty active this time of year, with music theory training applets which can capture MIDI and microphone input in-browser.
I could spend a year to rebuild what I can in JavaScript and HTML5 (there's nothing out there besides Java that'll give me MIDI input, of course), if I had a year to burn, which I don't.
Should I shut down the site entirely (and block thousands of users) because there are security issues appearing in OLD versions of Java, that many browsers don't even let you run anymore? Or should I just encourage browsers to keep refining their control over when applets can run -- so applets can be (again) simple to run by people who actually want them?
An unmaintained sandbox is worse than no sandbox at all because it gives a false sense of security.
The few who have to use it can keep using the old version and it being deprecated would put pressure on the websites that still use it to stop doing so.
If you're talking about the Java windows updater, IME it gives up really easily and then doesn't remember to update until the next patch goes out. Also, aborts if any other installer is running.
OTOH, the Linux openjdk package stays pretty up to date and doesn't install the Ask toolbar ;-).
All thus security issues in Java is bad enough, but the whole ask toolbar thing makes it even worse. Java should be auto updating as default. Instead they make us go thru the same wizard again and again, with only on goal; hope someone makes a mistake and install the ask bar.
Make my wonder if there other products may be dangerous too.
I've seen some machines where it tries to update with every release, and every release it fails with some cryptic error message, leaving the user on the old version. That can't be good for security.
Perhaps there's a reported bug for this, you could add a comment describing what you saw. If we report bugs in software then we're contributing to better software.
Uninstall it, then use ninite to install it again. This prevents adware from being installed and kills the update popups. http://ninite.com/ To update it later, just run the same ninite binary again; it will check for a new version automatically. Or, install Secunia's PSI which will silently update various programs in the background. http://secunia.com/vulnerability_scanning/personal/
Ha!
After my wife accidentally missed the checkbox and her laptop was "infected" with the Ask toolbar, I uninstalled Java on all my Windows machines at home.
Apparently I don't have any software that is depended on it. If I had known I would have uninstalled it a long time ago!
My cynical self would say that this is the perfect training for when XP runs out of support next April. Just because their vendor dropped support doesn't mean that usage will suddenly stop nor does it mean that no exploits are going to be found and used.
Right now it's "just" Java 6 which isn't installed on every machine out there (but still on a huge part of all Java capable machines). Next year it will be Windows XP which still has between 40% and 80% usage.
Me personally, I'm really interested how this is going to turn out. Will we see unofficial patches? Will we see anti virus vendors step up and provide semi-official patches? Will vendors have to cave and continue issuing patches? Will the malware issue just be ignored? What kind of damage does need to happen before something changes?
I'm in healthcare. We have a number of clinical applications that are only officially supported on J6 (and sometimes they even go so far as specifying specific updates that are supported). They actually work just fine on J7, it just requires tweaking a couple of security settings. But getting that across to non-technical managers that have had "You must be running J6u17" beat into their heads by idiot vendors is a bit of a nightmare.
the non-technical managers understand that the FDA only approved the J6 version of the app. If you want to use J7, you have to resubmit to the approval process.
The law is there for a reason.
SOME apps it won't matter... like maybe some billing or hospital transportation apps or something... but certainly anything diagnostic in nature cannot be run in a manner in which it was not approved.
J6u17 is honestly fine on a machine disconnected from the internet, as would be the case in any critical equipment requiring it. It's even relatively fine on an internet-connected machine with the browser plugin disabled (heck, Firefox automatically disables it for you).
40-80% usage in healthcare, the single slowest-moving IT environment there is (well, maybe industrial controls and space travel, but those aren't typically targeting Windows).
Maybe somebody will make a virus using an XP exploit that does nothing but patch the known exploits, propagate to other XP machines, and then delete itself.
I'm hoping that after one or two well-publicized and catastrophic breaches, management will realize that it doesn't make business sense to let critical infrastructure rot. I can't wait for the incredible improvements that would follow from no longer depending on applications that were frozen in time 14 years ago.
Why does Java have so many security holes? Is it really worse than any other language, or is it just so ubiquitous that it presents itself as a good target?
It's not the language that has holes - it's the java plug-in runtime. I agree that this gives java a bad rep but it really isn't related to the language all that much for normal non-plug-in usage.
Writing good sandboxes can be hard. Web browsers are pretty good at it but unlike java - they dont also have to support unsandboxed code running on the same VM so that makes things considerably easier.
It would have been nice if they had mentioned specifically what the problem was. To the layman, this article makes it seem like just having Java 6 installed on your computer puts you at risk.
"Applies to client deployment of Java only. This vulnerability can be exploited only through sandboxed Java Web Start applications and sandboxed Java applets."
Can someone explain to me the current title? From the CVE:
> Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 21 and earlier, 6 Update 45 and earlier, and 5.0 Update 45 and earlier, and OpenJDK 7, allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to 2D.
Doesn't that say Java SE 7 Update 21, as well as OpenJDK 7? Or is that new info since the title was written? HN should update accordingly?
To nit-pick, calling a bug that has been patched in a different version of Java for two months and exploited in this version at least a week ago a "zero-day" is quite a stretch of the term!
58 comments
[ 2.9 ms ] story [ 127 ms ] threadA total nightmare from a security perspective.
They are starting to roll out a version for mobile phones now, but it requires that your operator supports it and many will need a new sim card so it takes time.
In the meantime if you are out with your friend and you finds out you want to see a movie, you will have to walk to the theater or call a friend with a pc to buy a ticket. You can't just do it online from you iPhone (some movie theaters may have a app for that, but not where I currently live :( ).
It feels especially bad because it wasn't always like this. Before the massive adoption of Bank ID you could do almost anything online from your phone.
Norway: https://www.bankid.no/
Sweden: http://www.bankid.com/
The Swedish one uses native apps for Windows, Mac and Linux rather than java. Still trivial to attack from a trojan though.. :/
EDIT: To elaborate on jokc's reply (who appears to be shadowbanned), it seems that this exploit is only a problem for applications that use Java's sandboxing features, and the browser plugin is the best example of this -- but desktop applications can use these features too.
Sandboxes only apply in the browser, as far as I can think of -- Java code all executes in the context of a security manager, but does anyone actually set a custom security manager for running untrusted Java applications? (Maybe I'm just missing an example you know of...)
I'm afraid people do use it; of course the banks and so on (who probably can migrate to better solutions fairly easily); personally, I have a site that's pretty active this time of year, with music theory training applets which can capture MIDI and microphone input in-browser.
I could spend a year to rebuild what I can in JavaScript and HTML5 (there's nothing out there besides Java that'll give me MIDI input, of course), if I had a year to burn, which I don't.
Should I shut down the site entirely (and block thousands of users) because there are security issues appearing in OLD versions of Java, that many browsers don't even let you run anymore? Or should I just encourage browsers to keep refining their control over when applets can run -- so applets can be (again) simple to run by people who actually want them?
I'm leaning towards the latter.
The few who have to use it can keep using the old version and it being deprecated would put pressure on the websites that still use it to stop doing so.
AFAIK, Oracle Java 1.6.0 is EOL, and thus does not receive patches in a timely manner (if at all).
1: http://www.oracle.com/technetwork/java/javase/training/index...
Edit: I'm on 1.6
OTOH, the Linux openjdk package stays pretty up to date and doesn't install the Ask toolbar ;-).
Make my wonder if there other products may be dangerous too.
Apparently I don't have any software that is depended on it. If I had known I would have uninstalled it a long time ago!
* Go to: about:config
* Search "plugins.click_to_play"
* Enable.
Right now it's "just" Java 6 which isn't installed on every machine out there (but still on a huge part of all Java capable machines). Next year it will be Windows XP which still has between 40% and 80% usage.
Me personally, I'm really interested how this is going to turn out. Will we see unofficial patches? Will we see anti virus vendors step up and provide semi-official patches? Will vendors have to cave and continue issuing patches? Will the malware issue just be ignored? What kind of damage does need to happen before something changes?
the non-technical managers understand that the FDA only approved the J6 version of the app. If you want to use J7, you have to resubmit to the approval process.
The law is there for a reason.
SOME apps it won't matter... like maybe some billing or hospital transportation apps or something... but certainly anything diagnostic in nature cannot be run in a manner in which it was not approved.
Which is why biomedical engineering and IT are different departments. IT doesn't touch anything that directly touches a patient.
One of the applications I'm talking about is a physician portal meant specifically to be used over the public internet.
Ouch. That just screams 'this company doesn't understand security at all'.
Source?
This might finally be the end of IE6.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2463
https://access.redhat.com/security/cve/CVE-2013-2463
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b79d56eee... -- 4 month old fix
Why does Java have so many security holes? Is it really worse than any other language, or is it just so ubiquitous that it presents itself as a good target?
Most of these vulnerabilities are only applicable to environments which are required to run untrusted code.
Writing good sandboxes can be hard. Web browsers are pretty good at it but unlike java - they dont also have to support unsandboxed code running on the same VM so that makes things considerably easier.
"Applies to client deployment of Java only. This vulnerability can be exploited only through sandboxed Java Web Start applications and sandboxed Java applets."
> Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 21 and earlier, 6 Update 45 and earlier, and 5.0 Update 45 and earlier, and OpenJDK 7, allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to 2D.
Doesn't that say Java SE 7 Update 21, as well as OpenJDK 7? Or is that new info since the title was written? HN should update accordingly?