Latest Java Update Broken; Two New Sandbox Bypass Flaws Found

msm1267 writes "Oracle's long security nightmare with Java just gets worse. A post to Full Disclosure this morning from a security researcher indicated that two new sandbox bypass vulnerabilities have been discovered and reported to Oracle, along with working exploit code. Oracle released Java 7u11 last Sunday and said it fixed a pair of vulnerabilities being exploited by all the major exploit kits. Turns out one of those two bugs wasn't completely patched. Today's bugs are apparently not related to the previous security issues."

Enough Already

[Anonymous Coward]

Someone, please put Java in the browser out of our misery.

The same old story

[Synerg1y]

Java's had issues with reflection before: http://stackoverflow.com/questions/3002904/what-is-the-security-risk-of-object-reflection [stackoverflow.com] .

Considering that reflection is basically injecting code at runtime, I'd say most things in the Java world don't need it, not sure if it's on or off by default, but in 99% of scenarios I believe it should be set to off.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:I just have to say...

[Anonymous Coward]

Oracle is inept at pretty much everything.

FTFY

Re:Interesting

[dalias]

Yes, in some ways I agree it is a "smear campaign", but I don't think it's an unjustified one. When a product has had vulns this serious this many times, yet maintains huge deployment due to market dominance and user lock-in, a huge smear campaign is needed to destroy it. This was the case in the past with products like BIND, Sendmail, WU-FTPD, IIS, IE, etc. and Java is just the latest necessary target.

Re:The same old story

[Anonymous Coward]

Sorry to say: if you haven't seen reflection used in C# you must not have been looking very hard...

Re:The same old story

[Bob9113]

If Java's reflection features violate Java platform's security, it's an API design flaw, not necessarily a problem with reflection as such.

Java is a progamming language, like C. It has access to the filesystem and can fork processes. Security is handled by the operating system, just like C. Any permission that the executing user has, the language has. That is as designed.

The Java browser plugin, on the other hand, has a sandbox which is supposed to make it safe to run untrusted code. Turns out that trying to make it safe to run untrusted Java code is just as difficult as trying to make it safe to run untrusted C code. The security hole is in the Java sandbox, and in the notion of executing untrusted code in a language that has system access, not in the Java language.

For cripes sake... Java Plugin != Java

[diarrhea-uh-uh]

So sick of these headlines. Java is fine, it's the barely-used-these-days plugin that's the problem. I expect non-techy sites to omit that detail, but come on /. For those preaching that Java should be donated to Apache, give me a break. It's at the core of all "Enterprise Applications'" tech stack. Never gonna happen, nor should it. Best solution would be to decouple the plugin from the Java install and no longer shove it down people's throats.

Oracle doesn't get security!

[onyxruby]

I've said time and time again that Oracle doesn't get security, they just don't. They have been pulling things like this for a very long time. I never could have imagined saying this 10 years ago or so, but Oracle, you need to look at Microsoft for some pointers on handling security. Since you probably not willing to do that, I'll spell it out for you:

When you find out about a notable security flaw you need to have a patch ready to go within 60 days.
Meaningful notification. The everyday hacks that run IT need to have reasonable notification of security flaws.
Workarounds. If you can't fix it, that's fine, but give me a workaround or I'm going to start uninstalling your product.
How does it the flaw work? If you can't tell me how it works it means I have to reverse engineer it myself and this annoys me.
The difference between theoretical flaws and something that is broken beyond saving is typically 8-10 years.
The bad guys make a lot of money by counting on you dismissing security concerns.
You need to make it easier to administer updates to your products.
You need to make it easier to limit updates to your products. Why does Java 6 automatically update to 7? This is a bad, bad thing.

From a security standpoint I can't think of anything I would wish for more than the death of Java. Every chance I have to get rid of Java I put in my two cents to do exactly that.

Re:Enough Already

[Anonymous Coward]

From a user-experience point of view, doing that work to enable Java to work properly for Minecraft is an abortion.

Re:Enough Already

[robmv]

Already done, the previous u10 added options on the Java control panel (Windows) to disable all Java feature on the browser, so if you need Java for desktop applications, you don't need expose it to the browser.

Note: The Java plugin code was never open sourced to OpenJDK, people from IcedTea project developed a new plugin and JNLP engine for Linux. I am starting to think that Sun already knew the bad security quality of the plugin and they decided to never release that code

Re:Enough Already

[kbg]

This is one of the very stupid things Java has. The user has to set memory limits for the application, either using to much memory or too little, and the memory used is based on the usage for the application so that it is always a possibility to run out of memory for a Java application even if you have enough memory on your machine. This is a major usability and design flaw in Java.