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."
Someone, please put Java in the browser out of our misery.
Oracle need to be called out on what appears to be an open-and-shut case of negligence.
Only a complete idiot would take on Java and it's 600 million users without making some kind of plan for supporting it. Their approach so far has been unbelievably reckless.
I certainly hope they don't take that attitude to Oracle Database, which is very expensive indeed, and running inside companies with lots of well paid lawyers.
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.
Sorry to say: if you haven't seen reflection used in C# you must not have been looking very hard...
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.
Stop-Prism.org: Opt Out of Surveillance
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.