Java has recently been portrayed as a boogeyman than needs to be avoided. For months now, and almost everyday my twitter feed is filled with something concerning Java. From the tweets I get the clear impression that I have to disable it on my browser, or only use it on a separate browser or just completely uninstall it from my computer. Another thing I hear about is the constant discovery of new vulnerabilities and Oracle’s “patches” that seem more or less to be useless?
So what’s the deal here? How come all of a sudden Java is in the spotlight as the bad boy in security ?
Before I say anything here about the recent exploits. We need to make sure we’re talking about the right thing here. Simply saying Java is insecure and should be disabled is sort of misleading.
Java Usage
There are many ways in which Java could be used. A lot of banking and finance software is run using Java in the backend. Oracle makes heavy use of it (after all that’s one of the main reasons they bought Sun). Android apps need to be written in Java. Google code, SourceForge and github are filled with software written in Java. None of that code is really a concern at the moment. Java has been known as a technology that promotes portability (the so called write once run anywhere) and it’s lack of pointers make it safer for developers not to screw things up. Its memory management and utilization of multi-threading has been tested over and over again.
Java Applets
The main concern at the moment though is something called Java applets. One way Java could be used is in embedding software in a browser and allowing it to be run on a client’s local machine. This would allow users to run complex programs without the hassle of downloading and installing the programs themselves. Games are a perfect example. A more complex example is running a VPN session. Juniper, for example, implements its SSL VPN technology on the client side using an applet. That way the user is not involved in the intricate details of installing and configuring an SSL VPN client software. All what the user needs to do is visit a URL, maybe enter a username and password and they are good to go (assuming Java is enabled on their browser). The scary part is, of course, a remote server is running a program on my own machine and using MY local resources. What guarantees do I have that this program will not steal data from my computer and send it remotely to its own servers? This is where we start talking about applet security
Applet Security
Running remote code on a local machine was never not a concern. With ActiveX, for example, running untrusted code was more or less like downloading an exe file from a website and simply running it on your computer using your own privileges. If this was a bad website you simply have a virus on your computer. So, there started to be this whole trust model where ActiveX components need to be signed. Needless to say, that wasn’t really helpful. Users will trust anything to get it running. Applets on the other hand (untrusted applets that is), implemented this whole “Sandboxing” model by default, so unlike untrusted ActiveX code, they should not be a total disaster.
Sandboxing
This is how the “sandbox” model is enforced in a JVM
Sandboxing basically restricted what applets could do. An applet couldn’t, for example, access files on the system or read the clipboard. They cannot load native binaries or make network connections (they can make connections to the source of the remote applet). They can’t load classes to the JVM, otherwise they might just include their own security manager and bypass the existing one. It sounded like a balance was stricken between the restrictions for the sake of security and the usability of the Java libraries. But, as usual, security mechanisms could be broken. As early as 1997, there was an vulnerability involving the way code was being signed. An attacker could fake a signature that would label an applet a ‘trusted one’. Trusted applets operate outside the sandbox. There were many “lab-attacks”, which are attacks that were tested in a lab. As late as 2010 one of my professors mentioned that there was no evidence of a real applet attack in the wild.
Current Status
All that changed in the past year. I might talk about the details of the zero-day exploits introduced by the Polish firm Security Explorations and others in a separate blog. But it basically waters down to the fact that sandbox can be easily bypassed.
This would not be such a big deal really if it was simply a malicious remote program being installed locally. After all, malware have always been around. The main issue here is that many assumed Java to be simply “secure”. The false sense of security makes people use it with less reluctance. The other issue is that its portability made it even more dangerous since it can be distributed across different platforms. Mac OSX users always had the idea that their machine was much more secure than a machine running Windows. In 2011 the Flashback malware managed to infect hundreds of thousands of Mac OSX computers within a short period using a malicious applet. Linux is not safe either.
The Gist
So, when someone says disable or remove Java. Or that Java is insecure. It basically refers to the usage applets. So, if you’re an executive and someone wants to sell their banking software that uses Java don’t assume that it is not secure. Now, if they mention the need to run a Java plug-in on a browser, then you can start worrying.