New Java 0-Day Vulnerability Being Exploited In the Wild 193
Posted
by
Soulskill
from the once-more-unto-the-security-breach dept.
from the once-more-unto-the-security-breach dept.
An anonymous reader writes "Here we go again. A new Java 0-day vulnerability is being exploited in the wild. If you use Java, you can either uninstall/disable the plugin to protect your computer or set your security settings to 'High' and attempt to avoid executing malicious applets. This latest flaw was first discovered by security firm FireEye, which says it has already been used 'to attack multiple customers.' The company has found that the flaw can be exploited successfully in browsers that have Java v1.6 Update 41 or Java v1.7 Update 15 installed, the latest versions of Oracle's plugin."
Re:Surprise Surprise (Score:0, Interesting)
Sure, it's as secure as you want it to be. Java on the other hand, proves time and time again to be insecure wether you want it to be or not :/
Re:Surprise Surprise (Score:5, Interesting)
I think the people exploiting Java has a LONG list of vulternabilities in queue. With each update of Java, fixing the last known holes, they just update their exploit code to utilize the next vulnerability in their queue. This could go on for a long, long time.
And where I work, we have to use Documentum Webtop which requires Java. Now they have us pushing Java updates all the time.
Oracle needs to pay out a bounty for Java vulnerabilities so collect as many as possible so the next fix(es) will be better.
Re:Why does this VM have so many vulnerabilities? (Score:5, Interesting)
AFAIK all these issues are not in the VM.
The JVM has been stable for many years and is the foundation of countless information systems: websites, money exchange, traffic control, you name it they all run server-side software on the JVM, which by itself is rock-solid.
The issue is with the "sandboxing" feature of the Java browser plugin. The plugin was engineered to allow executing arbitrary, untrusted JVM bytecode, which would include outward calls to Java's extensive standard library, while still preserving some high-level definition of isolation between the untrusted code and the host OS. Given that Java's standard library is full of classes that do very insecure things by design (including running native code, opening network sockets, and so forth) this security model has proven to be a complete nightmare. They will keep finding sandbox-related bugs in the Java standard library for as long as it exists.
Oracle should do one of these things:
Re:why they don't (Score:2, Interesting)