Submitted by “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.”
Oooh, less laggy Minecraft…
Is it even possible to run Java securely on a desktop these days, especially as a browser plugin? Mind you, I’m not trolling here… I’m genuinely asking, based on all the zero-day Java attacks I’ve been reading about lately.
The first thing I did when I had a Mac was to delete the Java plug in (although it was a stub in recent versions which pointed to Mac OS X downloading the latest version I still didn’t like it ‘there’). I guess you could do the same with Java on Windows (I don’t have it installed) by disabling the Java plugin in both Internet Explorer and NPAPI browsers.
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
I’m not a security expert:
Except with Java, isn’t the vulnerability potentially cross platform? Whereas with native exploits, you’d have to write one for each different platform.
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.
At least in OpenJDK/JVM this might improve when project Graal gets integrated.
Graal is the project to integrate Maxime JIT which is 100% Java code.
The idea is to follow Jikes, Maxime and Squawk VM projects where the Java was used to write the VM, with a very minimal set of native code.
moondevil,
“Graal is the project to integrate Maxime JIT which is 100% Java code.”
I wasn’t aware, that’s very interesting. I wonder how you bootstrap such a thing. Do you need another VM to bootstrap the Maxime JIT’s code?
Nice diagram for a project you mentioned:
http://labs.oracle.com/projects/squawk/squawk-rjvm.html
“Even with VM exploits it depends on which VM you are using, there are many more out there, besides Oracle’s.”
I’m not ready to stop calling it Sun’s VM
Graal:
http://openjdk.java.net/projects/graal/
http://www.oracle.com/technetwork/java/javase/community/jvmls2012-1…
Graal is based on Maxime’s work,
https://wikis.oracle.com/display/MaxineVM/Home
In a way yes.
This paper provides a nice overview how bootstraping works,
https://wikis.oracle.com/display/MaxineVM/Technical+Report
The idea is quite simple, you use the JIT compiler offline to generate the basic VM image for the classes that take care of the VM ground work.
The compiler recognises special annotations that allow trusted Java code to perform unsafe operations, this minimizes the requirements to native methods.
Additionally you have a thin layer for the native methods.
Another example is the Jikes RVM,
http://jikesrvm.org/Presentations
What I miss is that the official JDK still lacks an AOT compiler, while other vendors do offer them. It is not easy to convince project managers to pay for native code compilers for Java, unless the project really requires them.
I used to write Sun/Oracle VM in the last months, but one needs to face the sad reality that Sun is gone.
You have to break out of the sandbox and what you do afterwards is platform dependent.
But does it? If a Java vulnerability allows the VM itself to be controlled, the exploit can just run Java code with full permissions.
Much like how in the past, MS Office’s Visual Basic potentially allowed malware to run on a Mac (again, not a security expert, so I don’t know if it ended up being just hype, like Y2K).
Well you can’t do anything useful for a malicious intent through Java.
(Unless you are going to send a few emails or something like it)
Edited 2012-10-11 15:36 UTC
What if the JVM is connected and authenticated to a database when the malicious program gets control. A malicious program can use JDBC to get sensitive information from that database without needing to go native.
kwan_e,
“What if the JVM is connected and authenticated to a database when the malicious program gets control. A malicious program can use JDBC to get sensitive information from that database without needing to go native.”
Can you elaborate the specifics of where this malicious program came from? The reason I ask is because we need to ask whether the same attack vector is significantly more likely to happen in java than a non-java program.
Did the administrator unknowingly install the malicious program in the first place? Did he install a trusted program that contains a remotely exploitable application vulnerability, which enables a remote attacker to install & execute the malicious instructions? Does the compiler contain a bug that can be exploited remotely execute malicious instructions?
All these things are possible, but ask yourself if Java is inherently less secure than other languages for running local programs. Escaping java’s sandbox is bad, but are there any instances where using Java is worse for security than using another languages like C, which doesn’t have any sandbox whatsoever? Is there something specific you think I’m overlooking?
I would think that having a portable malicious program is a completely different kind of worse. Java (but you can probably say the same for other cross platform VMs) runs almost the same on any platform, basically amounting to a monoculture. Whereas a C program would be hard pressed to work exactly as designed even for POSIX compliant operating systems, let alone in a realistic environment where there’s a mix of different server operating systems.
kwan_e,
“Java (but you can probably say the same for other cross platform VMs) runs almost the same on any platform, basically amounting to a monoculture.”
Oh ok…yeah I guess monocultures can be bad for security, competing implementations and variety can help limit the scope of a given attack. The same should be said for operating systems, applications, hardware vendors, etc.
We do have some choice in JVM’s today. If I were to guess, the Java diversification is probably somewhere between PHP (few competing implementations) and Javascript (many competing implementations). Who knows if we should count android or not, it is a Java language implementation after all, even if its files are not binary compatible.
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).
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?
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.
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.
Can you enlighten me how are you able to have more control over libc, libstdc++, msvcrt,… than Java developers have over JRE?
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.
As secure as any C or C++ application.
Press always fails to mention that the Java security exploits are not in the language, rather in the native code that compromisses the virtual machine, in case a VM is used at all.
When a VM is used, then the exploit is done via the data the methods implemented in C/C++ expect, or by trying to find out bytecode sequences that the VM’s verifier assumes are safe but are not.
Even with VM exploits it depends on which VM you are using, there are many more out there, besides Oracle’s.
Just disable the plugin or only let it run on certain domains.
if they made java compile with mingw on Windows and finish the tigershark port. OpenCL these days on GPU rely on closed drivers or open with partial documentation. Projects like (hopefully not vaporware) Parallela or Open Graphics aim to solve these problems. But until opencl/and hardwrae become open (in terms of HW interface, not necessarily inner workings) I believe manpower should be invested elsewhere. But it is their time spent and it was not easy. For this, congratulations are suitable.
The crux if java performance problems comes not from its raw number crunching abilities (it stands agains c++ in micro benchmarks) but its style of memory mamagement. Moreover JIT has its own memory overhead (runtime performance metrics, heaily instrumented code). Managing memory in pressured conditions takes time, not being able to share heavy runtime between processes adds to it.
Having jit take care of branch optimization also made priogrammers prefer more dynamic style (virtual by default). If they used it in C++ (with GC) the resulting runtime performance would be worse.
Is summ practical java lower performance is a price paid for programmers convenience more than inherent platform flaw.
Yep. Java definitely has issues with deterministic performance, but so do most GC’d platforms.
Java performance is not an issue, it’s better than most languanges(there’s a ton of benchmarks). The issue is JNI performance and deterministic(aka real-time) performance.
Edited 2012-10-11 12:19 UTC
If it feels slow and reacts slow…then it is slow.
Pretty much every single Java application I’ve ever used, server as well as desktop, pretty much used up all the RAM and ran like molasses.
Benchmarks are like asshole; everybody has one and you’ll be happier caring only about your own.