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

by Lightning • 13 years ago

101 79 13 years ago

thenextweb.com

ihuman• 13 years ago

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

jug6ernaut5• 13 years ago

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.

benmmurphy5• 13 years ago

what browser are you using and how are you disabling the plugins?

jug6ernaut5• 13 years ago

Google Chrome, under Settings, Advance Settings, Content Settings.

I have all mine ether set to not allow or only after click to play.

uglytom• 13 years ago

You can disable the java plugin in Firefox by going into tools->add-ons and disabling all the java add-ons.

k3n• 13 years ago

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:

    * site has pre-existing Java
    * site gets compromised somehow
    * site now infects users

This is how it usually plays out:

    * site gets compromised somehow
    * exploit includes a 0-day Java attack
    * site now infects users

Literally 0 sites on the net could be hosting Java applets and that would make no difference; it's the number of active Java plugins that creates the potential for mass-infection. So long as you have the Java plugin enabled, you'll be exposed to this attack.

jug6ernaut5• 13 years ago

Ah, fair enough.

sixbrx• 13 years ago

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.

epochwolf• 13 years ago

There are multiple applications I use at work that require java to be active with reduced security.

chime• 13 years ago

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.

jonknee2• 13 years ago

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

jonknee2• 13 years ago

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.

sleepyhead• 13 years ago

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.

Cigano3• 13 years ago

Not really? And the security plugin from my bank?

Florin_Andrei• 13 years ago

"Java security plugin from my bank" - irony is strong with that one.

pjmlp3• 13 years ago

Correction, new Oracle Java Virtual Machine exploit.

pslam2• 13 years ago

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.

pjmlp3• 13 years ago

Yes, however there are hundreds of JVMs available in the wild. Oracle's one is just the reference version.

martinced4• 13 years ago

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.

IvyMike2• 13 years ago

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

ChuckMcM• 13 years ago

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

elisee• 13 years ago

To disable the java plugin temporarily in Chrome, you can use chrome://plugins

JSadowski• 13 years ago

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.

sc0rb• 13 years ago

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.

tomjen34• 13 years ago

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.

drzaiusapelord2• 13 years ago

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?

dsl• 13 years ago

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.

drzaiusapelord2• 13 years ago

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.

trailfox• 13 years ago

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

Reply

JonSkeptic• 13 years ago

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

Reply

cleaver• 13 years ago

:) "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

Reply

martinced4• 13 years ago

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

Reply

yuhong• 13 years ago

I wonder if IcedTea could lead by provinding a faster patch cycle.

Reply

stusmall• 13 years ago

Or you can just disable the java plugins in your browsers. I think that might be slight overkill

Reply

acdha• 13 years ago

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

Reply

speeder• 13 years ago

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?

Reply

IvyMike2• 13 years ago

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.

Reply

ajross• 13 years ago

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.

Reply

ambrop7• 13 years ago

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.

Reply

kedean• 13 years ago

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.

Reply

lanstein2• 13 years ago

FireEye is an awesome place to work FYI. Lots of stuff like this.

Reply

lanstein2• 13 years ago

e.g. http://blog.fireeye.com/research/2012/07/grum-botnet-no-long...

Reply

__herson__• 13 years ago

*And this is not a repost.

Reply

Mahn• 13 years ago

World would be such a better place if we could get rid entirely of Flash and Java for the web.

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.

Reply

tomjen34• 13 years ago

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.

Reply

_delirium• 13 years ago

Flash still seems more popular for webgame development. I've run across a handful of HTML5 games, but many more Flash games. Not entirely sure why. Libraries, maybe? Is there something comparable to Flixel for HTML5?

Reply

Encosia• 13 years ago

There are solutions in the works, but precisely timed audio (like games need) is still problematic in HTML5.

Reply

Liongadev• 13 years ago

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

Reply

radd9er• 13 years ago

Using the html 5 video player sucks pretty bad in my experience (coursera).

Reply

0x2232• 13 years ago

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.

Reply

kicktheshoe• 13 years ago

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.

Reply

Apocryphon• 13 years ago

Does this give anyone else a flashback to IE days and ActiveX exploits?

Reply

coldtea• 13 years ago

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.

Reply

New Java 0-Day Vulnerability Being Exploited in the Wild

Related Stories