Paving Over the Proprietary Web: The Java Security Bigger Picture

Perhaps you’ve heard about the recently disclosed Java 7 zero-day exploit. The flaw allows a remote attacker to take complete control of a computer. It has been incorporated into many exploit kits. The Department of Homeland security regards the Java exploit as sufficiently serious to recommend “disabling Java in web browsers until adequate updates are available.” Oracle’s fixes — aren’t.

Many of my colleagues at other security firms have spilled a lot of ink describing why this particular Java exploit is bad. It is indeed that bad; Apple, for example, has forced down an update that blocks the Java 7 plugin from executing in the browser at all, at least until Oracle is able to distribute an update. If you are in the habit of keeping Java switched on in your browser, you should turn it off — of course. But that isn’t always possible. Client-side Java, for example, powers GoToMeeting. Many other companies — including my own — rely on client-side Java for critical functions. So one cannot simply rip it out, or mandate that it be banned. Reality has a habit of messing up the best-intended recommendations. But make no mistake, at some point very soon Java on the client needs to go. CIOs, please take note.

Client-side Java is part of the web’s proprietary past, and its time is ending. That proprietary past also includes ActiveX and Flash, two other technologies that saw widespread adoption in the early 2000s. That all three of these technologies came of age at roughly the same time isn’t a coincidence; they all filled gaps in the web experience. ActiveX was Microsoft’s way of adding native client functionality to a then-crude web experience; client-side Java (Swing, Java Web Start etc) did the same. Flash and its cousin ShockWave provided smooth video and animations.

Since 2005, though, the native web has changed dramatically, and for the better. HTML 5, CSS and JavaScript toolkits have been the major catalysts of a revolution in web design. The canvas element added to HTML 5, for example, allowed standards-compliant browsers to draw shapes, create and fill paths, and animate objects. This, plus the video element, freed designers from needing Flash. Cascading Style Sheets (CSS) Levels 2 and 3 gave designers increasingly pixel-perfect control over the placement and appearance of content — a task made even easier with CSS pre-processors such as LESS and Sass, and with kitted CSS assemblies such as Twitter Bootstrap. On the JavaScript front, third-generation toolkits such as jQuery made it simple to make websites dynamic and responsive. You can do all of these things for free, without needing to buy any of the various Studios from Adobe or Microsoft.

The slow-motion revolution in how the Web is made means that the raîson-d’être for proprietary web technologies is going away. Like a lumbering concrete mixer, HTML5 and JavaScript are slowly paving over the parts of the web that had previously been occupied by Flash, ActiveX and Java. Ironically, the vendors of these proprietary technologies have, in their own ways, added limestone, clay and water to the paving machine.

Microsoft, for example, turned an entire generation of web developers against it with its long, and ultimately fruitless, resistance against robust CSS support in Internet Explorer. Although modern versions of IE are highly standards-compliant, Internet Explorer did not pass the CSS Acid3 test until September 2011. Any web developer who has been working with CSS for more than 5 years, for example, can probably regale you with stories of massive hacks needed to allow older Microsoft browsers to work with standards-based websites.

The roots of Adobe Flash’s decline are a little different. Nothing was “broken” with Flash, functionally speaking.¹ Two related events resulted in a decline in Flash usage: Steve Jobs’ public refusal to add Flash support to the iPhone and successor iOS devices; and Google’s decision to convert its vast library of YouTube clips to HTML 5-compatible WebM and H.264 formats.

These actions, plus the increasing viability and efficiency of WebM and H.264, meant that you didn’t need Flash video any longer. This has clear implications for customers. For customer-facing websites, you can (and should strongly consider) retiring Flash video in favor of H.264. This is a quick win; the re-encoding process is relatively quick and painless. That said, the need is not as urgent compared to Java. Adobe’s security team (under the leadership my former @stake colleague Brad Arkin) has upped the tempo of bug fixes, adopted auto-update, and is taking security seriously enough that Flash has become less risky than it had been. Still, if you could remove a dependency on a third-party component that needs to be maintained and updated in addition to the base operating system, why wouldn’t you?

Java, on the other hand, is simply a mess. From a pure features perspective, Java’s caretaker parent, Oracle, no longer employs the kind and number of Java engineers that will keep it up-to-date — never mind put it back on the cutting edge. Most of the Java engineers and visionaries such as James Gosling, Josh Bloch, Tim Bray, Amy Fowler, and Adam Bosworth — the people I learned from and looked up to while I was learning Java J2EE — left long ago to greener pastures. Although server-side Java is still widely used, nobody I know would consider it for greenfield development for use with a browser.²

From a security standpoint, it is hard to see why Oracle would be Johnny-on-the-spot with security fixes. As my other (!) former @stake colleague David Litchfield has pointed out, the company doesn’t have the best track record on security. We can reasonably assume that fixing client-side Java security holes isn’t anywhere near the top of Oracle’s priority list. And even if it becomes so because screaming customers demand it, legacy products get legacy engineers. That’s just the way it is.

The same goes for Microsoft’s ActiveX. Developers don’t use it for new web-based projects, and the company has for several years recommended that developers use other technologies³ to make dynamic websites. The risks associated with ActiveX continue to be high, no doubt because ActiveX controls are basically chunks of native code written by various vendors of varying skill, remotely triggered by websites that may or may not be under the user’s control. (What could go wrong with that?) To be sure, Microsoft has done as much as any vendor in the industry to set the standard for responsible and secure development practices. Over the years, they have responded relatively quickly to the various ActiveX security issues that have popped up over the years. But as with client-side Java, it’s legacy technology maintained by legacy engineers.

It is much, much easier to talk about how the slow-moving concrete machine that is the modern web — HTML 5, CSS, and JavaScript — will slowly pave over the proprietary web. It is harder to state with confidence what it will mean for security. However, one may hazard a few guesses. The decline of these three technologies should increase the overall level of security over time. Logic dictates that a browser festooned with fewer proprietary plugins is a more secure browser. Put differently: migrating older websites to use CSS, HTML 5 and JavaScript support will have the effect of concentrating the attack surface by reducing the number of parties who must defend that surface. Over time, the broad public ought to be better served by having Apple or Google or Microsoft be responsible for the entire web browsing experience — including security.

But in the short term, it won’t be so clean. Based on vulnerability counts — an imprecise metric at best — the “younger guys” don’t score well. For example, the US National Vulnerability Database shows that the WebKit browsing engine had over 198 disclosed vulnerabilities last year. Internet Explorer? Just 61. Meanwhile, ActiveX, Java and Flash had 73, 169, and 67, respectively. I draw no other conclusions from these data, other than the simplest one — increased use of native browser capabilities is likely to increase risks in the short term, even as the decreased use of proprietary technologies decreases it over the longer term. At some point the two lines will cross and we will all be better off.

In the meantime, the cement truck keeps rumbling.