It's easy to think of Java as just being 'that thing that lets you play games in your web browser.' However, in reality, Java is much more than just a programming language. It's also a computing platform used by enterprises the world over to power vital business applications. Running on more than a billion computers and mobile devices, it would be surprising if Java had not gained the attention of the bad guys who look for big user-bases to exploit.
The problem for Oracle, which owns Java these days, is that despite patch after patch the vulnerabilities continue to be exposed and exploits launched in the wild to, well, exploit them. Java has seemingly, for all intents and purposes, become the new Microsoft as far as media reporting is concerned. Whereas the insecurity headlines used to firmly target all that was wrong with Windows, Internet Explorer and so on, now Java finds itself caught in the cross-hairs. But is this media crucifixion actually deserved? Let's look a bit more closely at what's going here in terms of the vulnerabilities in Java, what the recent zero-day exploits have been targeting, and how they work in the real world.
Java is not dead
"Basically, all software released today has bugs. Java is no different. Java is the primary development language for millions of developers, and the ecosystem is huge. It won't be going away any time soon, especially on the server side and for desktop applications. However, it may cause developers to pause when considering Java applets as a delivery mechanism for web application clients. If many users have Java disabled, your application won't work. I have no idea if Oracle will be able to move Java onto a more secure path. It's easy to take potshots from the outside and say that a development organization should just shift to faster patching. From the inside it's like laying new railroad tracks to shorten the distance from A to B. There's limited flexibility to make structural changes while the trains are already on a schedule; making big changes requires laying new processes down that affect the entire software development process, which may involve hundreds or thousands of people. It takes time, even when the organization is serious about it." Andy Chou, CTO of Coverity
"Java is a general purpose programming language that usually compiles into byte code that can be run in a virtual machine (the Java Virtual Machine), instead of the traditional way of compiling the program into binary code that can be run directly on the hardware," he said.
"That approach has several advantages such as 'write once, run everywhere' because the applications run in a virtual machine instead of real hardware, and the virtual machine can provide exceptional security because there's total control of the environment where the application runs. For example, Android runs a Java virtual machine and it is the centre of the platform. And, thanks to the virtual machine, we can run applications on our devices limiting the operations that the software can perform (the app requests permissions that need to be granted), and we can be confident that any other operation won't be permitted."
So we can seen that there are a couple of different things here that the 'media' tend to call Java: there's Java the language and Java the platform, plus you can then throw in the different implementations of the virtual machine for good measure.
The security incidents most recently reported are, in fact, mostly related to one virtual machine implementation in particular and do not highlight any broader language design flaw or architectural problem. As Martinez points out, the flaws do not even impact all the components of the Java platform but instead are limited to the Java Runtime Environment. Unfortunately this is installed in almost every browser on the planet by way of a plugin required to run Java applets.
Ziv Mador, director of security research at Trustwave, provides a bit of background about the Java browser plugin sandbox. "By design, a Java applet is not allowed to perform certain activities which might jeopardise the end user or the computer is runs on, such as stealing private information, installing malware, etc..." Mador explained.
He added: "In theory, running Java applets is safe. However, most of the popular Java zero days from the past year-and-a-half attempted to execute a privileged command which bypasses that sandbox, allowing that applet to gain elevated privileges on the machine it runs. So why wouldn't any Java applet execute that privileged command? Simple, because executing this command is forbidden to all but some core Java libraries. This is where the exploit authors kick in looking for missing security checks in those core libraries, causing them to execute the privileged command which disables the security sandbox, giving complete control to the crooks. Other popular zero days attempted to trick the way the Java runtime optimises performance, where there's usually less security checks, in order to get the same results."
So that's the background, but what about the technical specifics? Over to Dodi Glenn, who looks after the VIPRE Antivirus range at GFI Software. "CVE-2012-5076 was able to abuse the AverageRangeStatisticImpl, causing remote code to execute outside of the Java sandbox. With regards to CVE-2013-0422, according to cve.mitre.org, multiple vulnerabilities in Oracle Java 7 before update 11 allow remote attackers to execute arbitrary code," he said.
"[It does this] by (1) using the public getMBeanInstantiator method in the JmxMBeanServer class to obtain a reference to a private MBeanInstantiator object, then retrieving arbitrary Class references using the findClass method, and (2) using the Reflection API with recursion in a way that bypasses a security check by the java.lang.invoke.MethodHandles.Lookup.checkSecurityManager method due to the inability of the sun.reflect.Reflection.getCallerClass method to skip frames related to the new reflection API, as exploited in the wild in January 2013, as demonstrated by Blackhole and Nuclear Pack, and a different vulnerability than CVE-2012-4681 and CVE-2012-3174."
In a real-world scenario, the end user is either lured (typically via email) into visiting a website where this exploit is being hosted, or they may accidentally stumble upon a compromised website through what is called a drive-by download.
With a bit more clarity now about what Java is and where Java is going wrong, we can see that most of the problems with Java actually seem to be with the browser plugin, with Java that is running within the web browser.
