Slashdot Mirror
New Java 0-Day Vulnerability Being Exploited In the Wild
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."
JAVA - Just Another Vulnerability Alert
One Rich Asshole Called Larry Ellison
Executing random C code from somewhere on the net in a Browser is even dumber than doing the same with Java. Java at least has a security model, even if it's broken anew every week, and has more holes than a sieve. C on the other hand has nothing. It really is more or less like a portable Assembly Language as it was developed for.
Yes, C is secure. You can however use C to write buggy software, for example a java virtual machine.
c++;
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.
Unfortunately there is no "stupid" moderation. The issue is the Java sandbox which has the goal of letting you run untrusted code (e.g. applets) on your system without any worries. Unfortunately the attack surface of the sandbox is huge because there are so many different API's that are usable and all it takes is a bug in one of them to give you an exploit.
Turn off Java in your browser and you'll be a happy camper. Stop spreading FUD. The Linux kernel still has exploits (http://www.zdnet.com/linux-kernel-exploit-gets-patched-7000011844/).
Oh, and I spent 10 years as a kernel developer in C and another 10 years as a Java developer so I guess I'm a Real Hipster Programmer.
I think what he means is that C-security is solely dependent on your code, while Java-security is depended on JVM security in addition to your code security. And the developer has no control over JVM security.
I would say discussion of if a Turing complete is secure or not is off base. You can express any computable algorithm and if you get it wrong it may or may not behave in undesired ways when presented with input you did not anticipate.
Now if you want to discuss topics if interpreters (byte code or otherwise) that enforce certain memory management contracts, so you don't have to express them as part of your program ultimately offer better security or just move the problems that might be a valid topic.
Java is not insecure; security is not even an attribute you could put a value on with regard to Java. The browser plugins that ship with the most popular interpreter and runtime implementation might be insecure. There may be bugs in the interpreter where it does not properly enforce contracts making otherwise correct programs under it vulnerable. One little mistake in a C/C++ programs might result in the same thing though. The traditional argument is whats more likely to result in the best outcome: every programmer our there writes good code or a team of skilled programs writes a universal memory manager, and set of libraries that are solid so other programers don't have to get some of that hard stuff right?
I guess the issue is we are finding out more often than not even teams of very skilled developers are bound to slip here and there with something as large and complex as the Java runtime.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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:
I'm a hobby microcontroller programmer. I've made stuff with PICs that runs flawlessly. Written in C and assembly. One is a fan controller (switches 5 different relays and shows the output on a 7-segment display), and it's been running for probably 8 years non stop (well, the fan stops but the controller never does).
Another project was a simple "street block counter" for taxis, which I sold to a friend and he's made hundreds if not thousands of them (i should have asked more money!).
And tens of little projects that more or less work as supposed.
For all those projects, it's easy to validate all inputs and outputs, and follow all code. Since they're simple to understand. Right now my project is a weather station with ethernet and data logging. It's simple on the outside but it's so hard when you realize how much sanitizing you need for all values, and when you test it for different values of VDD and start getting weird readings, and when you deal with a memory chip which can (and will) be interrupted mid-write with a power outage and your data will be corrupted. It's really incredibly hard how you find more and more potential flaws after just a few hundred lines of code (and reasoning).
So while i understand your point, comparing java to a few small systems isn't really fair. Java is a huge monster with a target painted on its back. No system is really secure, and even Mac OS (which was claimed "secure") was proved to be as flawed as anything else. Mac OS used to be something no one cared about, but now that it's gaining a user base, it's being targeted more and more. It's the same with java. And it could be the same with any other language, tool (PDF), OS, SCADA, PLC, anything.
Any system that accepts uncontrolled (by the user) inputs is subject to exploiting.
The JVM is actually written in C++. Just sayin'
That explains a lot...