It's been less than a month since Oracle addressed what would have been an incredible 144 vulnerabilities with a critical patch update in January.
I say 'would have' because the Java security track record this last few years has, quite frankly, been scandalous. Most of those 144 vulnerabilities were in Java v, worrying enough in itself, considering that Java v6 had already hit the 'end-of-life' buffers and v7 was meant to be the secure saviour of the platform. Yet there we were, staring at the abyss that Java is fast becoming: 34 remote exploitation vulnerabilities fixed in the Java v7 update 51.
According to the latest Cisco Annual Security Report, as many as 91 percent of attacks last year could be traced back to insecurities in Java. The Cisco Vulnerability Research Team (VRT) showed that it wasn't just a case of zero days being exploited but rather worryingly also plenty of well-reported and previously known vulnerabilities in Java.
The exploit kit makers have been having a field day, simple as. With Java threats increasing at a rate of 14 percent year-on-year, according to Cisco, it comes as no surprise that the IT administrators and security specialists I speak to have been in agreement that Java for the desktop is a dead man walking. But where does that leave Java in the cloud?
When Cloud Pro contributor Adrian Bridgewater attended the Oracle launch of Java-as-a-Service last year he wondered if it would prove to be a 'sweet brew or a bitter grind?' Perhaps now we have an answer.
According to Polish security researchers at Security Explorations there are no fewer than 28 vulnerabilities in the Java Cloud Service. Adam Gowdiak, CEO at Security Explorations, says 16 of those are serious enough that they can be used in order to "completely break" the Java sandbox of a target WebLogic server environment. Gowdiak goes on to insist that an attacker could leverage this with a view to gaining "access to application deployments of other users of Oracle Java Cloud service in the same regional data centre”.
What does this actually mean? Well, as I understand it, it means that there is the potential to access user applications and database schemas. Oh, and let's not forget the now fully-expected old chestnut of executing arbitrary code on systems. The Security Explorations researchers say they have verified malicious Java code exploiting "a combination of identified vulnerabilities" which could be executed on a WebLogic server.
I understand that these vulnerabilities were present in versions 13.1 and 13.2 of Oracle Java Cloud Software and have been tested at both US and EMEA Oracle Java Cloud data centres. Gowdiak accuses Oracle of engineers of having a "weak understanding" of both the Java security model and the attack techniques used to exploit it. By way of responsible disclosure, Security Explorations sent a vulnerability notice with the proof of concept codes to Oracle on the 31 January, and further data on the 2 February. Oracle has confirmed successful receipt and is currently investigating the reported issues.
So what does this all mean for Oracle? Well, it's not good news that's for sure. I kind of feel sorry for the people trying to keep on top of security in Java, what with it being such a high profile target (Java suffers from the same 'top of the tree' problem as Microsoft), but corporate attempts to revive the brand by insisting, as it did in an official blog entry entitled Maintaining the Security Worthiness of Java is Oracle's Priority are not going to be helped by these latest revelations.
In particular, the Oracle insistence that "while the security problems affecting Java in Internet browsers have generally not impacted Java running on servers, Oracle has found that the public coverage of the recently published vulnerabilities impacting Java in the browser has caused concern to organisations committed to Java applications running on servers" is now looking prophetic at best and a little pathetic at worst.
Organisations would appear, on the face of it, to be right in showing that concern if the Security Explorations vulnerabilities are as serious as they sound. Multiple weaknesses that could be used to escape the Java security sandbox of a target WebLogic server environment, and problems within the applications validation process, do not good reading make.
The simple fact that this opens a possibility of reading and writing data, and executing arbitrary Java code on the target server instance that hosts other users' applications, is enough for me to think that Oracle is going to have to fire-fight on an almost unprecedented scale if it is to resuscitate Java (both within and without the cloud environment) from the, frankly, near terminal position it is fast approaching.
