Linked by David Adams on Tue 12th Jul 2011 19:08 UTC, submitted by HAL2001
Privacy, Security, Encryption 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.
Thread beginning with comment 480574
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Nice
by ebasconp on Tue 12th Jul 2011 22:42 UTC in reply to "RE[2]: Nice"
ebasconp
Member since:
2006-05-09

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

Reply Parent Score: 3

RE[4]: Nice
by Neolander on Wed 13th Jul 2011 07:51 in reply to "RE[3]: Nice"
Neolander Member since:
2010-03-08

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

Reply Parent Score: 1

RE[5]: Nice
by moondevil on Wed 13th Jul 2011 12:02 in reply to "RE[4]: Nice"
moondevil Member since:
2005-07-08

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.


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.

Reply Parent Score: 2

RE[5]: Nice
by JAlexoid on Wed 13th Jul 2011 14:50 in reply to "RE[4]: Nice"
JAlexoid Member since:
2009-05-19

May I try ?

And fail to single out Java?

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.

So is any .EXE file. What's your point? Java does not get a free ride as far as the OS is concerned...

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.

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 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.

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)

Reply Parent Score: 2