New Java 0-Day Vulnerability Being Exploited in the Wild(thenextweb.com)
thenextweb.com
New Java 0-Day Vulnerability Being Exploited in the Wild
http://thenextweb.com/insider/2013/03/01/new-java-vulnerability-is-being-exploited-in-the-wild-disable-the-plugin-or-change-your-security-settings/?fromcat=all
79 comments
Get everybody on at least IE 9 and then there is basically no reason to use flash.
Canvas + HTML5 video can basically anything people use to do today.
And yes I know, HTML5 development is my job.
Canvas + HTML5 video can basically anything people use to do today.
And yes I know, HTML5 development is my job.
99% of all Webbased gaming is flash. Why? Because HTML5 is about at a point where flash was 5 years ago. Thats not just my opionion but facts (see all game portals, FB game etc.) and what the big guys say (http://www.wooga.com/press/releases/wooga-html5-project-goes...)
Using the html 5 video player sucks pretty bad in my experience (coursera).
To disable the java plugin temporarily in Chrome, you can use chrome://plugins
Or permanently. I have never found a use for the Java plugin in my browser. And for all other plugins I have click-to-play enabled.
I use Java in the browser. The way you use your computer is not the same other people may use theirs.
We have a web based VPN tool that has to use Java.
We have a web based VPN tool that has to use Java.
I've had good experiences so far by keeping a dedicated browser for use with "legacy" services (such as school) that require Java. I haven't tried it, but I would suspect the profile manager in Firefox may help with that kind of setup, too.
Maybe a dedicated vm for anything that requires java would be safer these days. :/
I have two observations about that kind of plan.
First, it would be significantly more of a hassle to boot up a separate OS for the purpose of executing a short-lived task (such a submitting homework, or doing banking, as others have mentioned). Related to that, there is a slight disconnect between the host filesystem and the guest filesystem. The more convenience one has (e.g. greater transparency and sharing) the greater the risk.
Related, but separate from that: how would you know the VM was compromised and thus should be destroyed? One could presumably just periodically destroy (or revert to snapshot). Perhaps even if it was compromised, maybe the short lifespan of the VM would limit the damage to others.
First, it would be significantly more of a hassle to boot up a separate OS for the purpose of executing a short-lived task (such a submitting homework, or doing banking, as others have mentioned). Related to that, there is a slight disconnect between the host filesystem and the guest filesystem. The more convenience one has (e.g. greater transparency and sharing) the greater the risk.
Related, but separate from that: how would you know the VM was compromised and thus should be destroyed? One could presumably just periodically destroy (or revert to snapshot). Perhaps even if it was compromised, maybe the short lifespan of the VM would limit the damage to others.
Tell that to the entire country of Denmark where we are all bound to use a Java applet for such things as paying taxes or online banking.
Has anyone from Sun/Oracle commented on this yet? Are certain parts of the code being exploited? Have they done anything to secure the VM? Is it all just spaghetti code at this point?
Anyone from Oracle who commented publicly on this would most assuredly be promptly fired and sued.
These Java exploits are all pretty low hanging fruit. CVE-2013-0431 basically boiled down to calling "System.setSecurityManager(null)". We haven't even hit the advanced stuff yet.
These Java exploits are all pretty low hanging fruit. CVE-2013-0431 basically boiled down to calling "System.setSecurityManager(null)". We haven't even hit the advanced stuff yet.
That's some pretty wild speculation.
As for "boiling down to calling setSecurityManager(null)" you are forgetting to point out how it was achieved via obscure calls to an instrumentation and management api:
https://community.rapid7.com/community/metasploit/blog/2013/...
Their head of security spoke recently about this topic, so I guess they will have to "fire and sue" him: http://www.computerworld.com/s/article/9236230/Oracle_s_Java...
"The plan for Java security is really simple," said Java security lead Milton Smith during a conference call this week with Java user group leaders. "It's to get Java fixed up, number one, and then number two, to communicate our efforts widely. We really can't have one without the other. No amount of talking or smoothing over is going to make anybody happy. We have to fix Java." - See more at: http://www.computerworld.com/s/article/9236230/Oracle_s_Java...
As for "boiling down to calling setSecurityManager(null)" you are forgetting to point out how it was achieved via obscure calls to an instrumentation and management api:
https://community.rapid7.com/community/metasploit/blog/2013/...
Their head of security spoke recently about this topic, so I guess they will have to "fire and sue" him: http://www.computerworld.com/s/article/9236230/Oracle_s_Java...
"The plan for Java security is really simple," said Java security lead Milton Smith during a conference call this week with Java user group leaders. "It's to get Java fixed up, number one, and then number two, to communicate our efforts widely. We really can't have one without the other. No amount of talking or smoothing over is going to make anybody happy. We have to fix Java." - See more at: http://www.computerworld.com/s/article/9236230/Oracle_s_Java...
I'm thinking more of an official statement or something. I dislike the code of silence that a lot of these companies have regarding security.
I would guess those Java "0-day" vulnerabilities have been known for months or years.
It's just that now, because of the previous spread of 2-3 vulnerabilities, the publicity and the extra scrutiny placed upon Java bugs by Oracle, those holding on to them started selling/using them in fear that they will be discovered and patched soon.
It's a use-it-or-lose-it kind of thing.
It's just that now, because of the previous spread of 2-3 vulnerabilities, the publicity and the extra scrutiny placed upon Java bugs by Oracle, those holding on to them started selling/using them in fear that they will be discovered and patched soon.
It's a use-it-or-lose-it kind of thing.
I think I would be more surprised if the title of the article were "New Java 0-Day Vulnerability Not Being Exploited in the Wild"
...Maybe we could post news stories and not statements about 0 days being used because they're 0 days(especially if it's a Java or Flash 0 day)?
...Maybe we could post news stories and not statements about 0 days being used because they're 0 days(especially if it's a Java or Flash 0 day)?
:) "New Java 0-day Vulnerability" is like the headline: "Dog bites man".
"New Java 0-Day Vulnerability Not Being Exploited in the Wild" is the "Man bites dog" headline. :P
"New Java 0-Day Vulnerability Not Being Exploited in the Wild" is the "Man bites dog" headline. :P
The best thing to happen to Java was Google supporting Android. Now we have probably 5 more years of this mess until we get good adoption of a real linux phone, then Java will be tossed onto the already rotting corpse of flash.
Hardly worth bothering to reply to this sort of nonsense, but applets are a tiny tiny fraction of a percent of what Java is used for. Java and other JVM languages are use in most backend systems today and also by the likes of google, amazon etc.
FireEye is an awesome place to work FYI. Lots of stuff like this.
Java should change their logo from a coffee to some swiss cheese.
I want to know two things,
first: Why huge banks (the sort that net profit 10 billion) and other big organisations (like, governments) insist in using Java Applets for browser security and auth?
second: Why JVM is full of holes while JVM clones (like Dalvik and open source JVM substitutes for desktops) seemly are so much less affected?
I want to know two things,
first: Why huge banks (the sort that net profit 10 billion) and other big organisations (like, governments) insist in using Java Applets for browser security and auth?
second: Why JVM is full of holes while JVM clones (like Dalvik and open source JVM substitutes for desktops) seemly are so much less affected?
I would put my money that Dalvik etc is not inherently safer, it's just a matter of the JVM holes being fairly executable-specific attacks, and nobody bothering to target the off-brand JVMs.
I'm with you on the first part -- certainly there's nothing inherently different between the interpreter security models of the JVM and Dalvik.
But if you're counting by deployed units, the JVM is now the "off brand". Dalvik owns that market. Certainly it's no less an attractive target -- perhaps more so as mobile devices are now a bigger part of the consumer market.
But if you're counting by deployed units, the JVM is now the "off brand". Dalvik owns that market. Certainly it's no less an attractive target -- perhaps more so as mobile devices are now a bigger part of the consumer market.
This isn't really targeting the same kind of thing. These are Java applet sandbox exploits. Android machines don't run Java code they find on web pages. These are the same thing as finding a bug in the Flash plugin or the browser.
I think security bugs in Dalvik have less ramifications, because of at least 2 reasons:
1. Java code doesn't get executed by Dalvik automatically from web sites etc - an attacker has to get the user to install his application.
2. If an attacker manages to get the user to install and run his application, Dalvik security bugs are close to useless to him because Android applications can load native code without needing permission from the user. His problem is going to be circumventing the restrictions enforced by the kernel and system daemons running on the system. Android doesn't enforce permissions at the JVM level AFAIK.
To clarify here I meant vulnerabilities in the JVM that have to be triggered by malicious Java bytecode. Vulnerabilities which make applications themselves vulnerable are more problematic of course.
1. Java code doesn't get executed by Dalvik automatically from web sites etc - an attacker has to get the user to install his application.
2. If an attacker manages to get the user to install and run his application, Dalvik security bugs are close to useless to him because Android applications can load native code without needing permission from the user. His problem is going to be circumventing the restrictions enforced by the kernel and system daemons running on the system. Android doesn't enforce permissions at the JVM level AFAIK.
To clarify here I meant vulnerabilities in the JVM that have to be triggered by malicious Java bytecode. Vulnerabilities which make applications themselves vulnerable are more problematic of course.
Banks are notoriously bad about updating their technology practices. They didn't really stop using DES in their ATM's until it was required by law that they update to 3DES in 2002 (DES encryption has been theoretically broken since the 80's and practically, that is it was done in something like 17 days, broken since the 90's). For them, the potential losses from java exploits just don't outweigh the price of switching the infratstructure in place.
Does this give anyone else a flashback to IE days and ActiveX exploits?
*And this is not a repost.
For the devs on Linux who actually need Java (e.g. Java or Clojure or Scala devs etc.), then there's an easy way out.
Do NOT install Java from your distro. Do NOT install Java by giving the root password (or by directly using the root account): no rpm, no deb.
Fetch, from a regular user account, the Java .tar.gz and install Java in your dev user account.
And then install your browser in another user account.
This is what I do.
This way you can be sure and certain that no amount of Sun / Oracle uber retardedness Java applets can ruin your day....
Do NOT install Java from your distro. Do NOT install Java by giving the root password (or by directly using the root account): no rpm, no deb.
Fetch, from a regular user account, the Java .tar.gz and install Java in your dev user account.
And then install your browser in another user account.
This is what I do.
This way you can be sure and certain that no amount of Sun / Oracle uber retardedness Java applets can ruin your day....
> Do NOT install Java from your distro. Do NOT install Java by giving the root password (or by directly using the root account): no rpm, no deb.
This advice is fundamentally confused about how computer security works: the issue is not how the code is installed, it's whether an attacker can get your browser / email client to execute it. If the code runs as you, it has all the access it needs even if the files are owned by root.
> Fetch, from a regular user account, the Java .tar.gz and install Java in your dev user account.
So I don't get updates from the very responsive Ubuntu / Debian groups and instead rely on obsessively checking the news? That seems a LOT worse than simply disabling the Java browser plugin.
This advice is fundamentally confused about how computer security works: the issue is not how the code is installed, it's whether an attacker can get your browser / email client to execute it. If the code runs as you, it has all the access it needs even if the files are owned by root.
> Fetch, from a regular user account, the Java .tar.gz and install Java in your dev user account.
So I don't get updates from the very responsive Ubuntu / Debian groups and instead rely on obsessively checking the news? That seems a LOT worse than simply disabling the Java browser plugin.
Or you can just disable the java plugins in your browsers. I think that might be slight overkill
I wonder if IcedTea could lead by provinding a faster patch cycle.
There have been [__0] days since the last Java exploit.
"You know, one of these days, we're going to use that second digit.” — Stephen Colbert
"You know, one of these days, we're going to use that second digit.” — Stephen Colbert
I dont understand all the fus around these exploits. Are they exploits? Yes. Do people actually use java in the web? Not really.
Maybe im in the minority but i never see java applets, and i think i browse ~ the avg. Of course i also disable all plugins until i click on something.
Maybe im in the minority but i never see java applets, and i think i browse ~ the avg. Of course i also disable all plugins until i click on something.
It makes no difference how prevalent they are in common web apps, the problem is that the Java plugin is still installed and active for a large number of users.
This is not the attack sequence:
This is not the attack sequence:
* site has pre-existing Java
* site gets compromised somehow
* site now infects users
* site gets compromised somehow
* exploit includes a 0-day Java attack
* site now infects users
Yes - also even a user who only wants to use client side Java outside of the browsers may be in trouble because of the automatically installed browser plugins that are part of the Java installation process.
It's incredible how far and fast client side Java has fallen because of Oracle's tepid response to security concerns. I've developed many internal apps for client-side Java and supported them for over a decade. I don't think I'll develop another.
It's incredible how far and fast client side Java has fallen because of Oracle's tepid response to security concerns. I've developed many internal apps for client-side Java and supported them for over a decade. I don't think I'll develop another.
It has nothing to do with Oracle's response -- the Java sandbox is simply broken, and has been known to be broken for at least the last 5 years. There's no fixing it, the approach is fundamentally flawed and fundamental to Java.
This doesn't mean that Java for client-side applications is broken, as long as you don't rely on web based distribution and browser sandboxing.
This doesn't mean that Java for client-side applications is broken, as long as you don't rely on web based distribution and browser sandboxing.
Can you elaborate on "the approach is fundamentally flawed"?
Don't we rely on a similar sort of sandboxing for Javascript in the browser?
Don't we rely on a similar sort of sandboxing for Javascript in the browser?
java sandbox has a massive surface area. conceivably any class in the jre could create a hole in the sandbox. modern browser sandboxes appear to be stronger because they rely on an unprivileged process which communicates with a broker interface. the broker code is much smaller than the jre code so it is easier to verify. however, there has been sandbox bypasses. the adobe sandbox bypass was a bug in the broker interface and it can be possible to use local kernel exploits to bypass the sandbox as well.
"This doesn't mean that Java for client-side applications is broken[...]"
I don't know. Java on the desktop requires administrator privileges to be able to notify me that an update is available. Also, it tries to install a virus in the form of "Ask toolbar" every frigging time.
I don't know. Java on the desktop requires administrator privileges to be able to notify me that an update is available. Also, it tries to install a virus in the form of "Ask toolbar" every frigging time.
Try installing using http://ninite.com, and use msconfig to make sure "Java Platform Auto Updater" is disabled from your startup.
Oh you don't know my misery : (
I'm actually working on a desktop app used by hundreds of people (and installed by thousands) and my entire business model is being an ISV: trying to sell that Java app to people.
The less Java installed, the harder my life becomes ; (
I'm actually working on a desktop app used by hundreds of people (and installed by thousands) and my entire business model is being an ISV: trying to sell that Java app to people.
The less Java installed, the harder my life becomes ; (
Are there JREs which you can secretly include in your package, so that it looks like a few-hundred MB native application which happens to be implemented in Java?
Ah, fair enough.
User googles for 'digital camera nokia review' and ends up on a site containing a specially crafted 1x1 pixel Java applet. User doesn't even know it's there but due to the 0-day exploit, the applet can now download a remote executable to the user's machine and execute it. User's computer is now part of a botnet and all the user did was perform an innocuous google search.
Yes or it could be a site they visit regularly that has been hacked. Or a site that hasn't been hacked but that has JS from an ad network on it that has been hacked or let through a vulnerability. These are very scary hacks.
Update: I wrote up my recent experience of a shady advertising buy that appears to have spreading malware (likely via Java) as a goal http://news.ycombinator.com/item?id=5305092
Update: I wrote up my recent experience of a shady advertising buy that appears to have spreading malware (likely via Java) as a goal http://news.ycombinator.com/item?id=5305092
Considering Facebook and Apple devs getting owned by these exploits I think the answer is yes. That you even know what a plug-in is does make you in the minority, but considering who has been victim so far you should not sit back with such a smug attitude.
In Norway most banks require payments have to be verified with BankID which uses a Java-applet to enter a one-time password.
Most people in larger organisations who makes decisions about IT have no clue what they are doing.
Most people in larger organisations who makes decisions about IT have no clue what they are doing.
There are multiple applications I use at work that require java to be active with reduced security.
what browser are you using and how are you disabling the plugins?
Google Chrome, under Settings, Advance Settings, Content Settings.
I have all mine ether set to not allow or only after click to play.
I have all mine ether set to not allow or only after click to play.
click to play is not a security feature and will not prevent malicious plugins from running.
Are you sure? As far as i understand it until you click on the plugin the plugin is not loaded at all.
If you visit a malicious site and click anywhere on the page (not on a plugin) then you could enable a click 2 play plugin. i raised this as a chrome bug and they said click 2 play is not a security feature. there may be even worse bypasses :(
the only way to have proper security is to disable the plugin. there is a button on the address bar that allows you to enable plugins on a page when they have been disabled. this gives you a similar experience to click2play but it is quite annoying especially if you are used to click2play.
the only way to have proper security is to disable the plugin. there is a button on the address bar that allows you to enable plugins on a page when they have been disabled. this gives you a similar experience to click2play but it is quite annoying especially if you are used to click2play.
Wow...well thats good to know! Doesn't really make sense, especially when you load say a YouTube webpage and it says "click to RUN adobe flash".
That is really misleading! :\
That is really misleading! :\
It is "click to run", the problem is, it might be disguised such that ANY click on a webpage might set it off.
Relevant Chrome click-to-play bug report:
Click-to-play doesn't actually require click to play
http://crbug.com/174963
Click-to-play doesn't actually require click to play
http://crbug.com/174963
I can't reply further down the comment thread, but can you provide an official source on this. I enabled this feature last week, and there's no way of interacting with the plugin until I click on it.
firefox has the same problem with it's click to play implementation. bug is not private so i will link to it: https://bugzilla.mozilla.org/show_bug.cgi?id=838999
You can disable the java plugin in Firefox by going into tools->add-ons and disabling all the java add-ons.
Not really? And the security plugin from my bank?
"Java security plugin from my bank" - irony is strong with that one.
You got my point.
I'm SCJP since the last century and my life has been developing Java since a lloonngg time (and now Clojure, but targetting the JVM).
Honestly the retards who decided that a Java applet was a wise decision for a bank should be shot before their genes are passed to a new generation :-/
Honestly the retards who decided that a Java applet was a wise decision for a bank should be shot before their genes are passed to a new generation :-/
You should visit Brazil.
There are lots of these wise decisions in IT here.
There are lots of these wise decisions in IT here.
Correction, new Oracle Java Virtual Machine exploit.
Is it actually a JVM exploit, though? From FireEye's blog it sounds more like a library exploit which allows unconstrained clearing of memory, which then leads to a JVM escape because it blows away the JVM state. I wouldn't class that as a JVM exploit.
Yes, however there are hundreds of JVMs available in the wild. Oracle's one is just the reference version.
But the point still stands that this specific exploit is NOT a JVM exploit? Is it an actual exploit of the JVM implementation, or just the libraries?
The problem has always been that Sun shipped way too big a runtime for Java applets - the entire Java SE - when they should have made a third class ("edition") for browsers. That's a huge attack surface, and that's were most of the exploits have been, including this one, unless someone knows otherwise.
The problem has always been that Sun shipped way too big a runtime for Java applets - the entire Java SE - when they should have made a third class ("edition") for browsers. That's a huge attack surface, and that's were most of the exploits have been, including this one, unless someone knows otherwise.
Regardless of what is being exploited it is only effective in Oracle's implementation.
Every JVM vendor has their own implementation, both runtime and libraries.
Every JVM vendor has their own implementation, both runtime and libraries.
To be honest they inherited all these applets (and applets-only) security exploits from Sun. Sun are the ones to blame here.
Actually the ones to blame are the uber f^^^tards who thought that Java applets was a technology worth anything.
One should go back in time and read Usenet's comp.lang.java.programmer from back in the early Java days. There were two camps: the retards who thought applets were a good idea and going to revolutionize the Web and the enlighted ones who pointed out that it was all wasted energy on a piece of shitty technology that would only create problems.
I was in that latter camp and, honestly, it feels good to see that no-one is disputing anymore that Java applets were really one of the most f^^^tarded piece of technology ever invented.
Actually the ones to blame are the uber f^^^tards who thought that Java applets was a technology worth anything.
One should go back in time and read Usenet's comp.lang.java.programmer from back in the early Java days. There were two camps: the retards who thought applets were a good idea and going to revolutionize the Web and the enlighted ones who pointed out that it was all wasted energy on a piece of shitty technology that would only create problems.
I was in that latter camp and, honestly, it feels good to see that no-one is disputing anymore that Java applets were really one of the most f^^^tarded piece of technology ever invented.
So, speaking as one of those fucktards[1], the idea that two third parties could possibly create interactive content without the participation of a standards body in the middle was a pretty neat idea. The 'pure render view' which was most commonly espoused early in the debate had the challenge that going from idea, to something people could use, took 6 months at a minimum and a year typically.
Since you were there you no doubt experienced the amazingly slow progress of <table></table> support in HTML as it got pushed out to the #1 source of browsers (AOL) on a very slow timeline. The period between 1993 (can't use tables in your web pages because no one except XMosaic users have them) to early 1995 where "most" but certainly not a preponderance of web browsers supported them.
Some level of programability between client and server was essential. Had the 'render only' view prevailed you wouldn't have Javascript either. But it didn't prevail.
That said, security has always had a sort of anti-thetical relationship with 'features.' Its easy to sell features and its hard to sell security. I had built the basics for a nice capabilities based security model for Java early on (even patented it with the NSA's approval), which created a durable way giving only specific capabilities to an applet in a way that made other capabilities not only not accessible but not even present in the running system.
It was a bit more complex than the way class loading had traditionally been envisioned, it really crushed my motivation when another engineer on the Java project deleted it out of the source tree because he couldn't understand it.
The point I make is that these things evolve, and the story is never as simple as it looked like once you've gotten to the end of it. Should I have pushed harder on conceptual security even though it was hurting my career? Probably. Would it change where we are today? Hard to say.
[1] http://www.greatcircle.com/firewalls/mhonarc/firewalls.19950...
Since you were there you no doubt experienced the amazingly slow progress of <table></table> support in HTML as it got pushed out to the #1 source of browsers (AOL) on a very slow timeline. The period between 1993 (can't use tables in your web pages because no one except XMosaic users have them) to early 1995 where "most" but certainly not a preponderance of web browsers supported them.
Some level of programability between client and server was essential. Had the 'render only' view prevailed you wouldn't have Javascript either. But it didn't prevail.
That said, security has always had a sort of anti-thetical relationship with 'features.' Its easy to sell features and its hard to sell security. I had built the basics for a nice capabilities based security model for Java early on (even patented it with the NSA's approval), which created a durable way giving only specific capabilities to an applet in a way that made other capabilities not only not accessible but not even present in the running system.
It was a bit more complex than the way class loading had traditionally been envisioned, it really crushed my motivation when another engineer on the Java project deleted it out of the source tree because he couldn't understand it.
The point I make is that these things evolve, and the story is never as simple as it looked like once you've gotten to the end of it. Should I have pushed harder on conceptual security even though it was hurting my career? Probably. Would it change where we are today? Hard to say.
[1] http://www.greatcircle.com/firewalls/mhonarc/firewalls.19950...
> the retards who thought applets were a good idea and going to revolutionize the Web
Didn't this happen? I mean, the "applets" we use are all called "Flash" and not "Java", but Flash is everywhere, from ads to video to music. When the so-called "retards" were envisioning a future web, I though that's what they wanted.
Didn't this happen? I mean, the "applets" we use are all called "Flash" and not "Java", but Flash is everywhere, from ads to video to music. When the so-called "retards" were envisioning a future web, I though that's what they wanted.
It's not only the exploits, the fact that they are so frequent also means users got to update both Java and Flash almost every single day, which is a terrible user experience.