
New Java 0-Day Vulnerability Being Exploited in the Wild - Lightning
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
======
ihuman
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

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

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

~~~
_delirium
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?

~~~
tomjen3
Createjs?

Or just write your own.

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

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

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

~~~
stock_toaster
Maybe a dedicated vm for anything that requires java would be safer these
days. :/

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

------
pjmlp
Correction, new Oracle Java Virtual Machine exploit.

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

~~~
ChuckMcM
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...](http://www.greatcircle.com/firewalls/mhonarc/firewalls.199509/msg00353.html)

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

~~~
trailfox
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/...](https://community.rapid7.com/community/metasploit/blog/2013/02/25/java-
abused-in-the-wild-one-more-time)

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...](http://www.computerworld.com/s/article/9236230/Oracle_s_Java_security_head_We_will_fix_Java_communicate_better)

 _"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...](http://www.computerworld.com/s/article/9236230/Oracle_s_Java_security_head_We_will_fix_Java_communicate_better#sthash.JRKW306C.dpuf*)

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

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

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

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

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

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

~~~
lanstein
e.g. [http://blog.fireeye.com/research/2012/07/grum-botnet-no-
long...](http://blog.fireeye.com/research/2012/07/grum-botnet-no-longer-safe-
havens.html)

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

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

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

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

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

------
__herson__
*And this is not a repost.

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

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

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

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

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

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

~~~
BigBlueSaw
Can you elaborate on "the approach is fundamentally flawed"?

Don't we rely on a similar sort of sandboxing for Javascript in the browser?

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

