New Java 0-Day Vulnerability Being Exploited in the Wild
thenextweb.com
thenextweb.com
"You know, one of these days, we're going to use that second digit.” — Stephen Colbert
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.
Canvas + HTML5 video can basically anything people use to do today.
And yes I know, HTML5 development is my job.
Or just write your own.
We have a web based VPN tool that has to use Java.
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.
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.
Every JVM vendor has their own implementation, both runtime and libraries.
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.
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.
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...
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.
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...
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.
...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 Not Being Exploited in the Wild" is the "Man bites dog" headline. :P
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?
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.
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.
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....
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.
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.
I have all mine ether set to not allow or only after click to play.
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.
That is really misleading! :\
Click-to-play doesn't actually require click to play
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
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.
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.
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.
Don't we rely on a similar sort of sandboxing for Javascript in the browser?
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 ; (
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
Most people in larger organisations who makes decisions about IT have no clue what they are doing.
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 :-/
There are lots of these wise decisions in IT here.