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 538243
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Security
by Alfman on Thu 11th Oct 2012 03:50 UTC in reply to "Security"
Alfman
Member since:
2011-01-28

WorknMan,

"Is it even possible to run Java securely on a desktop these days, especially as a browser plugin?"

I don't know how well the java browser plugin security is faring these days?

However as a local desktop platform I don't think Java deserves too much criticism since the language has never been less secure than native apps in the first place. Consider that anything which manages to break out of the java sandbox through a java vulnerability is still access-limited by the same user-space restrictions as a non-VM language like C. While a vulnerability is disappointing, the worst case scenario is that the java app gains access to the same userland syscalls that a native C app can access anyways.

Browsers are at risk because they run untrusted arbitrary code from the internet and they rely on the VM to isolate applets from the main browser process.


Edit: This may be a bit tangential, but another security consideration might be to factor in the likelihood of code written in language X or Y to contain vulnerabilities. I'd assume that Java's strict typecasting and bounds checking rules, as well as general lack of pointer arithmetic make it less likely for Java applications to contain severe (non language related) vulnerabilities.

Edited 2012-10-11 04:05 UTC

Reply Parent Score: 4

RE[2]: Security
by kwan_e on Thu 11th Oct 2012 04:01 in reply to "RE: Security"
kwan_e Member since:
2007-02-18

I'm not a security expert:

While a vulnerability is disappointing, the worst case scenario is that the java app gains access to the same userland syscalls that a native C app can access anyways.


Except with Java, isn't the vulnerability potentially cross platform? Whereas with native exploits, you'd have to write one for each different platform.

Reply Parent Score: 2

RE[3]: Security
by Alfman on Thu 11th Oct 2012 04:58 in reply to "RE[2]: Security"
Alfman Member since:
2011-01-28

kwan_e,


"Except with Java, isn't the vulnerability potentially cross platform? Whereas with native exploits, you'd have to write one for each different platform."

Hmm, I'm not exactly sure what you mean. If you're talking about a vulnerability in code written in java, then yes that would probably be vulnerable on every platform supporting java. However this would not be an instance of a bug in the Java VM, but rather an application specific bug.


If your talking about a vulnerability in the Java VM, then it may or may not be a cross platform vulnerability. Remember that the VM itself is a native application that has to be written to support every target platform. A bug in the just-in-time-compiler for x86 isn't necessarily going to appear in the JIT compiler for x86-64 or ARM.

For the sake of argument though, let's pretend Java contained a backdoor and there was *zero* security in the VM...this would preclude Java as a viable platform for browser applets since malicious websites could gain access to your local account using the backdoor.

Now consider an application you download to run locally, you have the choice of either a native binary or a java version. Can you see why having a backdoor in the Java VM isn't an additional security risk compared to the native version? Even with the VM backdoor, the java application would be on equal footing with the native application security-wise. Both would be subject to the same userspace access as imposed by the kernel.

Reply Parent Score: 2

RE[3]: Security
by JAlexoid on Thu 11th Oct 2012 12:25 in reply to "RE[2]: Security"
JAlexoid Member since:
2009-05-19

Except with Java, isn't the vulnerability potentially cross platform?

You have to break out of the sandbox and what you do afterwards is platform dependent.

Reply Parent Score: 2

RE[2]: Security
by tracul on Thu 11th Oct 2012 09:16 in reply to "RE: Security"
tracul Member since:
2011-08-21

However as a local desktop platform I don't think Java deserves too much criticism since the language has never been less secure than native apps in the first place. Consider that anything which manages to break out of the java sandbox through a java vulnerability is still access-limited by the same user-space restrictions as a non-VM language like C. While a vulnerability is disappointing, the worst case scenario is that the java app gains access to the same userland syscalls that a native C app can access anyways.


The difference is that you can write "perfect" java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control)

Reply Parent Score: 1

RE[3]: Security
by the_trapper on Thu 11th Oct 2012 11:19 in reply to "RE[2]: Security"
the_trapper Member since:
2005-07-07

The difference is that you can write "perfect" java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control)


Until you link against third party libraries. A lot of browser flaws aren't actually Microsoft, Mozilla, or Google's fault. They are due to flaws in things like libjpeg, libpng, or openssl. Java applications are no different, you can think of Java as a big third party library. Even drivers, firmwares, and BIOSes have been known to have remotely exploitable vulnerabilities in them.

As a programmer, you never have all the code "under your control" unless you go to extreme lengths like
designing your own hardware, firmware, and operating system from scratch.

Reply Parent Score: 2

RE[3]: Security
by moondevil on Thu 11th Oct 2012 11:20 in reply to "RE[2]: Security"
moondevil Member since:
2005-07-08

The difference is that you can write "perfect" java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control)


Can you enlighten me how are you able to have more control over libc, libstdc++, msvcrt,... than Java developers have over JRE?

Reply Parent Score: 2

RE[3]: Security
by Alfman on Thu 11th Oct 2012 14:52 in reply to "RE[2]: Security"
Alfman Member since:
2011-01-28

tracul,

"The difference is that you can write 'perfect' java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control)"

I disagree. A "perfect" ANSI-C program can still be vulnerable to libc bugs (aka malloc, fscanf, etc).

Also, modern C code compilation can be incredibly complex. There are memory barriers, aliasing constraints, auto SIMD/pipelining, overflow assumptions, threading related bugs, etc. A bug or bad assumption in any of these features might be remotely exploitable (ie a JPEG rasterization library).

To the extent that a JIT compiler is more complex, I'll grant you that it is more likely to contain bugs, but bugs are inherently possible whether the code compilation happens ahead of time or at run time.

Reply Parent Score: 2