It’s not quite the development freeze Microsoft underwent during the Trustworthy Computing push, but it’s a start for Oracle, which will delay the release of Java 8 until Q1 of next year, largely because the platform and browser plug-in is such a security disaster.
This year has done nothing but reinforce that notion. Start where you will, with any number of zero-days, watering hole attacks, or a pair of takedowns at Pwn2Own, Java has taken a beating from hackers in 2013 and apparently enough is enough.
Mark Reinhold, chief architect of the Java Platform Group, took to his personal blog last week to announce that the next version won’t make its scheduled September GA date.
“Maintaining the security of the Java Platform always takes priority over developing new features, and so these efforts have inevitably taken engineers away from working on Java 8,” Reinhold said. “Looking ahead, Oracle is committed to continue fixing security issues at an accelerated pace, to enhance the Java security model, and to introduce new security features. This work will require more engineer hours than we can free up by dropping features from Java 8 or otherwise reducing the scope of the release at this stage.”
In other words, see ya next year Java 8. Not that many people would miss it.
For months, you’ve had experts from a number of security, development and IT organizations tell you flat out: “Disable Java.” And for the average Web user, that’s a feasible strategy. Disabling the plug-in won’t impede the average browsing experience. Websites functionality won’t be impaired and you’ve lessened your exposure to exploits targeting the technology. It’s on the business end where disabling Java becomes a sticky proposition. Any number of home-spun applications rely on Java, as do some pretty well-deployed commercial mobile banking, e-government and enterprise services applications. Disabling Java means real costs to those organizations and an impact on availability of services.
So that puts the onus on Oracle to right its ship in a hurry. Larry Ellison has yet to issue a landmark Gates-esque memo, but maybe he should. Rather than Unbreakable, maybe Ellison should formally put the capital-B Broken label on Java. The industry would surely say “No, duh, Larry,” but it’s a start—admitting you have a problem is generally considered the first step on the road to recovery.
Java is everywhere, making it an attractive target for hackers. Exploits targeting previously unreported vulnerabilities have been folded into a number of popular commercial malware kits. You can also find free attack code on Pastebin and a number of other online sources. It pays to attack Java; just ask the Tibetans, the defense industrial base, mobile developers at Twitter, Apple, Microsoft and Facebook, and any one hosting a website that’s been popped by a Java exploit since Christmas.
It’s a mess.
Not that Oracle hasn’t tried. A slew of security enhancements have been added to Java in recent months around code signing and new prompts warning users that a Java applet could be unsafe. The warnings have shields, are color-coded and there’s bold red text hammering the message home. Neat. Problem is that, much like Microsoft back in the day, by taking this approach Oracle tries to turn the user into a security admin. Users don’t want to be admins. They want their apps. They will click Yes, Run, Save, Execute—whatever it takes to get their apps or funny cat video. And hackers know this. And they’ll trick users into clicking on a harmful applet by spoofing Oracle’s dialog box and security warnings, twisting and turning them in their favor.
Locking down Java 8 is a start. Oracle is putting some key features on hold with this decision and has given itself a yearlong cushion to get its security house in order. For years security experts have been asking Oracle when its Trustworthy Computing moment will come and maybe this is the start. As Reinhold confirmed, security will be a priority going forward.
“If we sacrifice quality in order to maintain the schedule,” he wrote, “then we’ll almost certainly repeat the well-worn mistakes of the past, carving incomplete language changes and API designs into virtual stone where millions of developers will to work around their flaws for years to come until those features—or the entire platform—are replaced by something new.”
We’ll see…
