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
...is busy colonizing Hawaii.
One Rich Asshole Called Larry Ellison
just set a team of 10-15 experienced programmers to review the code in a period of 3-4 months instead of just-wait-to-see-the-next-exploit-and-fix-just-that-rinse-and-repeat ?
p.s. I have disabled java in my browser since ages. the only reason i keep still installed is because of ps3mediaserver. I wish it wasn't written in java so I could say goodbye to java once and forever.
C is "secure" now? ...
Surprise, surprise indeed
Aberrations have appeared in my destiny prognostication engine!
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.
Well, then you would both be wrong. C doesn't have a security model to exploit. The security model for loading untrusted code into your C application is "Don't do that" which isn't such a bad idea, really. However, if you remove the stupid idea of trying to run untrusted code in a sandbox within your application, Java is quite secure which is why people write server code in Java. No buffer overflows to start with (a classic exploit of server code written in C)
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.
A few things are different:
1. People dislike Oracle as a company
2. The purposes/reasons for exploiting have shifted significantly
3. Sun was likely more friendly to people presenting information about bugs to be fixed.
Yes, C is secure. You can however use C to write buggy software, for example a java virtual machine.
Ok explain why a simple string can buffer overflow? Maybe the latest Gnu C libraries have fixed that now, but damn that is bad as 10 years ago you could! The apis had to be practically rewritten to watch for these like these which explains why it is litered in secure versions of standard function calls.
The problem is you can't really write secure in C unless you know assembly. My simple "give me 2 numbers and I will add them" 10 line program will not look insecure but it is underneath after being compiled (this was 13 years ago I tried this). I know Theo from the OpenBSD tried making secure versions of standard ansi C functions to prevent this. Java at least tries and manages it. I can make the same argument that Java is secure. It is only the programmers who are not etc.
http://saveie6.com/
I agree but I'm a little confused if your agreeing or disagreeing with me. C gives you the power to do what you want, Java on the other hand assumes.
He's not exactly disagreeing or agreeing with you, as you're so thoroughly confused that you manage to say things that aren't cleanly true or false.
C has no security model. At all. This lets you write things that are totally unsafe. For example, you couldn't have browser exploits with either Flash or Java or any other plugin if it wasn't for the NPAPI, which is a C interface! O! M! G!
Java does have a security model; it tries to segregate untrusted code away from trusted code and ensure that the untrusted code can only do very limited operations. This is hard to get right. (Doubly hard when you've got the plugin glue code in the mix; that just makes everything much more complex.) For most applications, this actually doesn't matter very much as they don't load code from untrusted sources at all; Java is doing just great at powering web application servers, and there are some wonderful libraries to help with this. Browser plugins though are a different beast; their whole point is to load untrusted code and execute it, and any mistake is a problem.
Right now, I recommend disabling the Java plugin in all browsers that you use, or even better removing the plugin entirely. If you must have it enabled (for some horrible corporate web application) then only turn it on when strictly necessary. As a bonus, you won't have to suffer from nasty slow Java-implemented ads. (That was why I originally turned it off in my systems; being defended against hacking was a side benefit.) Also, Java tends to look like ass in a browser these days.
"Little does he know, but there is no 'I' in 'Idiot'!"
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
> Yes, C is secure.
The comment is nonsensical. Security is about vectors. The language itself, is really not "secure" because it has to operate within an environment. By integration, it's no more or less secure than the environment AND the program the language was used to write. You really don't understand the implications of the discussion if you think that comment was "excellent".
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 pretty sure the semicolon should come before the closing curly brace...
The main difference between C and Java, is that in C you code the bugs personally - in Java, that functionality is baked into to the JVM.
Comes down to who's programmers you trust more - your own, or Oracle's ?
EMail: 0110001101100010010000000110001101110010 0110000101111010011011100110000101110010 0010111001100011011011110110
No, honestly, writing evil code in C is easy. You can open files without restrictions, modify them without restrictions, and so on, all with the power of the running user. Executing untrusted C code is NOT SECURE.
Strings don't overflow in C, unless you use them wrong.
And you never know, there might be a vuln in the Java string library. Unless you've audited it, I wouldn't say there isn't, since it seems there are vulnerabilities everywhere else.
"First they came for the slanderers and i said nothing."
Nope its the damned games. Minecraft and Pogo and a shitload of other damned Java games have been released and become REAL popular which means a shitload of java installs that can be pwned. Its a damned shame, I saw Java practically disappear from the non corporate desktop only to see java all over the damned place now.
ACs don't waste your time replying, your posts are never seen by me.
It's a shame there isn't a really good open source alternative to Oracle's JVM that people could switch to. At least with the endless stream of Adobe Reader vulnerabilities you can just witch to Sumatra PDF or one of the many other free viewer applications.
As far as I can can tell most of the free JVMs are either abandoned or don't run on Windows.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
And who writes their whole program in using just their own code? We have massive C libraries because we cannot reinvent the wheel every time. And it isn't possible to exhaustively check the code in those libraries due to time constraints and sheer complexity.
Oracle cannot dismiss the damned plugin altogether, they have too much that relies on it, Oracle Forms for one. I'm unsure how that relates to their databases. Are they storing mobile code in their databases for use in their OF crap? OF seems particularly brain dead and I wouldn't mind them blowing it away and replacing it with native apps...but then they'd probably only produce them for MS's rinky-dink OS or Linux which doesn't have much use on the desktop.
AFAIK all these issues are not in the VM.
If you read the article, this is a buffer overflow in the VM itself, overwriting internal VM structures. In previous cases you'd be correct, but this is an actual JVM flaw.
The issue is with the "sandboxing" feature of the Java browser plugin.
The sandboxing feature isn't unique to the Java plugin. It's a built-in part of the Java runtime. Any Java code can place other Java code into a security context and enable the Java sandbox for that code. It's just that about the only place you'll ever actually see this done is for applets.
You are in a maze of twisty little relative jumps, all alike.
The JVM is actually written in C++. Just sayin'
That explains a lot...
The difference is that C CAN be secure if you code it right. In Java, even the most trivial thing you write remains dependent on the JVM to be actually secure.
That doesn't mean your C code WILL be secure, but if it's not it is your fault and entirely up to you to fix it.
The sandbox was designed back in the mid '90's. I don't think anyone realized just how hard securing things really is. One of my friends worked with Ed Felten at CMU back then and that team showed a number of exploits for the sandbox. When he showed me how some of them worked I was impressed - because my mind doesn't bend into pretzels that way to figure out exploits.
The best thing Oracle could do at this point would be to just shoot applets in the head (probably not going to happen). Second place would go to running each applet in a separate process and it's own OS contained sandbox the same way everybody else is. The attack surface of the OS is smaller and better tested.