Linked by Thom Holwerda on Wed 10th Oct 2012 23:47 UTC, submitted by MOS6510
Java "Java is a programming language that allows developers to write once and deploy everywhere - from high-end gaming desktops to smartphones. Its OS-agnostic and widespread nature is one of its strongest selling points, but one area where it can fall flat is performance. Generally, Java applications are not going to perform as well as native applications written for a specific OS. However, thanks to Project Sumatra that performance gap may soon become less of an issue."
Thread beginning with comment 538437
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Security
by JAlexoid on Fri 12th Oct 2012 00:39 UTC in reply to "RE[6]: Security"
JAlexoid
Member since:
2009-05-19

It's not like it's one JVM for the whole OS. And there is no local IPC mechanism in Java. If the JVM is connected to a DB, then you it's already within your sandbox.

At most what you could do is steal the encrypted trusted keystore at most(quite useless without a targeted attack).

Reply Parent Score: 2

RE[8]: Security
by kwan_e on Fri 12th Oct 2012 02:43 in reply to "RE[7]: Security"
kwan_e Member since:
2007-02-18

If the JVM is connected to a DB, then you it's already within your sandbox.


So as long as the malicious program is in a sandbox, you wouldn't mind it having full access to the database's data?

You do realize that the biggest reward to be gained from security breaches is information, not control, right?

Reply Parent Score: 2

RE[9]: Security
by moondevil on Fri 12th Oct 2012 07:34 in reply to "RE[8]: Security"
moondevil Member since:
2005-07-08

If the application does not validate the input it gets from the outside world, nasty things will happen even within a sandbox environment.

For example, if the application reads SQL from somewhere, it better pre-parse those SQL strings, otherwise something other than the developer expected will happen.

Many sandboxed environments, including Java and .NET, do have the possibility to enforce security at the method level, but this is usually only done in enterprise applications. And even then, the developer should take care of validating the input anyway.

The security issues with languages like C, is that it is enough for someone to miscalculate one pointer manipulation to expose the application.

Other more type safe languages usually force the hacker to manipulate the generated assembly code to achieve the same exploit.


The situation will only improve when C and C++ disappear from the tooling stack, or when everything is sandboxed, micro-kernel style.

But then we are again back to the problem that even with, lets call it, Safe C, the developer is not off the hook to validate the application's inputs.

Reply Parent Score: 2