Oracle’s Java platform is so troubled the question is whether to patch it, or kill it off.

2145480_m Oracle Inc. released its latest Critical Patch Update (CPU) on Tuesday of last week, with fixes for 113 vulnerabilities spread across its product portfolio, including 29 for Oracle’s Fusion Middleware, and 20 for the troubled Java platform. The release has prompted a chorus of entreaties to “patch now,” including those from the SANS Internet Storm Center, U.S. CERT and Brian Krebs. A surprising number of them, however, also held out the possibility of not patching Java and, instead, just not using it. This isn’t loose talk. It wasn’t that long ago that the headlines were all about new, critical security holes discovered in Java. Exploits for those vulnerabilities were used in online ‘drive by download’ and ‘watering hole’ attacks aimed at high value targets, including employees at companies like Facebook, Apple and Microsoft. The advice back then was to simply turn Java off – and leave it off – when you browse the web.

“Oracle/Java is probably by now one of the most successful charities in the world,”

- Daniel Wesemann

The furor over Java’s vulnerability subsided – even if the attacks and patches didn’t. Eight of 20 vulnerabilities fixed by Oracle in Java were rated 9.0 or higher on a severity scale of 1-10. One of them, CVE-2014-4227, rated a perfect “10.” All the reported vulnerabilities would allow a remote attacker to exploit the vulnerability without first authenticating (signing in) to the vulnerable system. The difficulty with Java is that it is a technology that is integrated into so many devices and applications – web based and otherwise. Oracle boasts that Java runs on 97% of enterprise desktops and 3 billion mobile phones, as well as countless embedded devices, from “smart” TVs to Blu-ray Disc players. That makes any exploitable vulnerability in Java worth its weight in gold for cyber criminals or nation-state backed hackers. A Java exploit is the key that will unlock just about every door on the Internet. The cost – to society – is large. “Oracle/Java is probably by now one of the most successful charities in the world,” wrote Daniel Wesemann on the SANS Internet Storm Center blog. “It continues to do an outstanding job at enabling significant wealth transfer to support poor cyber criminals and their families.” Java’s time may have come and gone. More than a few of the security experts calling attention to the latest CPU are asking out loud whether it isn’t time to ditch Java altogether. “Patch It or Pitch It” was Mr. Krebs headline – which aptly summed up the feelings of many security experts. Like the owners of an old junker, Java users may look at this latest CPU and ask themselves “is it really worth the trouble to patch?”

Widely adopted programs tend to make for more lucrative mines.

Widely adopted programs tend to make for more lucrative mines.


Where does the blame lie? The truth is that technologies that are widely adopted and deployed almost always attract the attention of cyber criminals. Active X was a popular back in the ‘dotcom’ era. It also became a favorite target of cyber criminals. Over time, that pushed developers and software publishers away from the platform and to alternatives…like Java. Technologies like Java are so ubiquitous that it can be impossible for anyone – individual or a business – to know whether a given product uses a vulnerable component until its too late. But, as competitors like Microsoft have endeavored to make their software update and patching process transparent, Oracle has opted to keep its security process extremely opaque. The company’s monthly CPU releases are massive and stretch across scores of disparate products and platforms. Some vulnerabilities affect multiple products, making it hard to know what’s going on. Researchers who dig for details often come away scratching their head. For the latest patch, Ross Barrett, a security engineer at the firm Rapid7 points out that the top two patches for Oracle Database 12 fix an issue that Oracle patched in an earlier version of the same product a year ago. That would suggest that Oracle either failed to appreciate the reach of the vulnerability last year or knew about it and chose to leave Oracle 12 customers unprotected. Either is troubling. In response, Oracle management – including Chief Security Officer Mary Ann Davidson, are often combative rather than conciliatory. Ms. Davidson recently penned a derisive blog post, “Those that can’t do audit” to cast doubt on the utility of code audits and suggest that large companies like Oracle shouldn’t have to bother with third party audits like the little guys. The message, on security: “trust us.” As the critical vulnerabilities in Java, MySQL and Oracle’s other products mount, however, trust is getting hard to come by.

About Paul Roberts

Paul Roberts is an experienced technology writer and editor that has spent the last decade covering hacking, cyber threats, and information technology security, including senior positions as a writer, editor and industry analyst. His work has appeared on NPR’s Marketplace Tech Report, The Boston Globe,, Fortune Small Business, as well as ZDNet, Computerworld, InfoWorld, eWeek, CIO , CSO and He was, yes, a guest on The Oprah Show — but that’s a long story. You can follow Paul on Twitter here or visit his website The Security Ledger.

Comments (1)

Jeremy | July 24, 2014 1:58 pm

When writing about java and security, you kind of have to differentiate between sandbox vulnerabilities and everything else. Java's sandboxing has been known to be terrible for quite a while and all the serious vulnerabilities seem to be there. So arguing that we shouldn't run untrusted code is completely legit. But aside from enterprise-type apps, there really aren't a whole lot of java applets out there on the web these days (my impression anyway) and browsers are getting better at forcing users to opt in to running applets on certain approved sites.

But of course, java is very popular for running non-sandboxed stuff (server-side apps, desktop apps, phone apps that are either trusted or have some other permissions limiting system) and I'm not seeing evidence that there is a problem with any of that. So any talk of killing off java really doesn't make much sense unless you specify that you're only talking about running untrusted, sandboxed code.

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.