ACROS Security has discovered a vulnerability in Sun Java, which can be exploited by malicious people to compromise a user’s system. The vulnerability is caused due to the application loading an executable file in an insecure manner when an out of memory condition occurs.
Just one more reason why I won’t be installing Java on my machine anytime soon.
That’s a pretty lame reason.
Yes, a flaw in the JVM is scary, just as flaws in kernels or popular libraries are.
The trade-off is that applications written in Java are less likely to have dangerous flaws than applications which execute directly, such as those written in C++.
As kernel and VM developers are much more likely to be aware of security than typical application programmers, I’ll take that trade.
Then you’re not on Windows, I guess? Considering you’re such a security nut. Or you’re just a person with a personal grudge against Java.
Well, Windows itself is not inherently insecure, unless you run insecure programs, like Java. For this reason, I don’t run Java at all, and only Flash when absolutely necessary, with Flashblock turned on at all times, except for a handful of sites that I have whitelisted.
(Of course, Java itself isn’t actually a program if you want to get technical about it, which makes it even worse.)
Edited 2011-07-12 21:45 UTC
Could you please elaborate more on why do you think Java is so insecure for your mission critical computer?
Java, as any application, may have its security holes, but as someone told before, Java is just a process, same as your freecell.exe or your winword.exe and the capacity of damage it has is the same than the capacity of damage the user that launches it has.
So, if you run your Java apps as an administrator or as a user with elevated privileges, Java is not the problem, but you!
But, I do not know, please elaborate more.
(if you do not consider Java to be a program (process, application, etc.)… then you are more dangerous for your computer than Java itself
)
Edited 2011-07-12 22:43 UTC
May I try ?
Java is an interpreter, and current OS security models are not designed to explicitly support interpreters. For the OS, an interpreter is just a black box executing arbitrary code from the wild.
What this means in turn is that Java may only run code as privileged as the Java interpreter is. So the Java interpreter must run with privileges that are as high as possible. No true OS-level sandboxing is possible.
Which means that the JRE is a huge mass of code (basically reinventing the system API for the sake of portability) running in a highly permissive security environment, without DEP/NX protection. As lots of code is statistically synonymous of lots of bugs/exploits, this is a disaster waiting to happen.
(Of course, if good OS-level support for interpreters was provided one day, the extreme case being an interpreted OS like Singularity, this argument would be void. Also, this is less of a problem for interpreters which maximize use of the system API instead of re-implementing everything, like C#/.Net on Windows)
(EDIT : And you’ll probably say that we don’t even use sandboxing for normal user apps currently, making even freecell.exe able to wipe the user’s home if exploited. Current desktop security sucks really badly. But to the best of my knowledge, all current OSs have some form of support for apps that voluntarily sandbox themselves, which is probably what you’ll want to use on your mission critical computer.)
Edited 2011-07-13 08:02 UTC
Java is a programming language. Unless you are referring to a specific implementation I fail to see which Java is an interpreter.
Regarding implementations, Sun JVM is a JIT since version 1.3. You can force fully JIT by setting the interpretation threshold to 0.
GCJ compiles Java to binary code.
Excelsior JET compiles Java to native code.
Other comercial JVMs like JRocktIT and IBM JVM follow similar JIT compilation methods like Hotspot.
And fail to single out Java?
So is any .EXE file. What’s your point? Java does not get a free ride as far as the OS is concerned…
Well… Duh! It’s privileges are the same as the user that started the process. In fact, Java doesn’t even have process user changing functionality built in. You can run Java in whatever sandbox you may wish. In addition, you may enable Java’s security features.
Which environment are you talking about? Desktop apps, that are even worse when it comes to security? Applets, that are probably more secure than the browser they run in in most cases(see number of IE users)
If you wan’t Java to be secure, then turn on Java security. Otherwise, you could just read up what this “hubbub” is really all about. Critical is only the title of the poorly written post…
Java is no less secure than .NET in this instance.
The last Java update had patches for 29 vulnerabilities, 15 of which are highly severe. Java is very insecure, and is a big gateway for PC penetration.
http://blogs.pcmag.com/securitywatch/2010/10/oracle_updates_java_to…
Edited 2011-07-12 20:49 UTC
Come on! Every large application releases a lot of security patches every time and that does not make them inherently insecure.
But how, sir, are you going to play minecraft 😮
And install Mono ?
There’s not a lot of info in the post.
Is there a problem in the jar or .class loader, which when presented with invalid input results in out-of-memory and arbitrary code execution?
Or do you need to load an applet which can then trigger the OOM+Execution?
There’s quite a difference – #1 could be really bad, #2 would require the user clicking “yeah, rape me” button to load the (probably unsigned) applet first.
A bit more information here.
http://www.h-online.com/security/news/item/Java-vulnerability-demon…
It seems that your own machine has to be compromised, for you to have this issue. It basically runs any specified application when you open an HTML file in Windows with Safari and IE.
I see security vulnerabilities among all platforms, browsers ect. springing up constantly.
Unfortunately Java vulnerabilities get much more bad press than the others. Think its a bit unfair.
*nod* From what I’ve hear, the most popular targets these days are JITed runtimes (Java, Browser Javascript, ActionScript, etc.) because, since they dynamically generate native code, they get minimal benefit from Hardware DEP/NX-bit protections.
Makes me wonder what kind of progress we’ll see in areas like static analysis and clever techniques like the “write code that generates your JIT” approach PyPy and luaJIT use.
(I’m also kind of curious why Google hasn’t tried repositioning Native Client as a framework for simplifying adding a sandbox around hand-coded JITs, given the claims they’ve made)
Edited 2011-07-12 20:18 UTC
As far as I know, .NET is also a JITted environment.
That net-security little post has no info at all. Only a sensationalist title.
http://www.h-online.com/security/news/item/Java-vulnerability-demon…
Better run a deep scan with an up to date antivirus tool. Seems this flaw is finding it’s way into allowing Trojans.