Microsoft's experience shows us what to expect from Oracle's Java 'security push'

It has been a very rough year for Java from a security point of view.

Two-thousand thirteen started with a number of zero-day attacks targeting Java, including those that resulted in breaches at Microsoft, Facebook, Apple and Twitter. As the year went on, the Department of Homeland Security and others recommended disabling or even uninstalling Java. Apple went so far as to effectively block the Java 7 web plugins twice in one month on OS X. As the security situation around Java seemed to deteriorate, the criticism of and frustration with Oracle continued to increase.

Then in April, Mark Reinhold posted on his blog that Java 8 would be delayed while Oracle redeployed development resources to secure the current versions of Java. And then at the end of May, Nandini Ramani posted a number of improvements that Oracle will make not only in the technology but also processes and procedures.

At the height of the worry about Java, some people were saying that it is the new Internet Explorer. Whether or not that's a fair characterization, one thing is certain: Oracle is definitely taking pages out of Microsoft's playbook -- right after the Trustworthy Computing Memo came out in early 2002. In contemplating the tenth anniversary of that memo, I wrote that for the next 10 years that memo's significance may be in how others follow its example. With Oracle engaged now in what amounts to a "security push" for Java, we have the first clear example of someone following Microsoft's example. Oracle deserves credit here for doing the right thing.

In looking at this situation, as someone who was at Microsoft during those times, I think it's instructive to go back and look at how this played out so that we can better understand what may lie on the road ahead for Oracle and everyone who cares about Java. Because one thing that we learned on our path at Microsoft: it's a long, hard road to achieving better security after announcing a new focus on it.

Things will Get Worse Before They Get Better

To set the stage, it's helpful to look at the timeline around the Trustworthy Computing Memo and actions it set in motion that ultimately resulted in major improvements in Windows (and Internet Explorer). The security push began with cofounder Bill Gates' January 2002 memo. The "security push" (also sometimes called a "stand-down") was a halt to active development while the entire Windows development organization was sent to security training. This was mandatory training for all developers, testers and program managers. This push also saw a major reprioritization of resources off of the next version of Windows onto service packs for the then-current version, Windows XP. This prioritization would culminate in the release of Windows XP Service Pack 2 in August 2004, two-and-a-half years after the push was announced.

Between 2002 and 2004 lies 2003, probably the worst year in the history of Microsoft security. January 2003 saw the return of crippling worm attacks in the form of Slammer, which targeted a vulnerability that had been patched in July 2002 with MS02-039 (a case that I handled). It was the first major worm attack since NIMDA in September 2001 and the first since the Trustworthy Computing Memo. Then, in August 2003, Blaster came through crippling networks that had barely recovered from Slammer.

These attacks drove Microsoft's security push to be increasingly aggressive. Windows XP SP2 was code-named “Sledgehammer” in a sign of how it was meant to crush these bugs with extreme prejudice.

Windows XP SP2 was a success in that regard and really marked a turning point. After Windows XP SP2 shipped it wouldn't be until Conficker in 2008-2009 that we would see another large scale network worm affecting Windows. And, touch wood, we haven't seen any since then.

But the fact that Slammer and Blaster came after the security push was well underway highlights the lesson that we typically see an increase in attacks in that window after a security push is announced but before its results are released. This is due to two things:

  • First, you still have the same product out there that you had before announcing the push. Attackers continue their work that led to the announcement in the first place: they're not stopping.
  • Second, not only are they not stopping, but announcing a security push amounts to "last call": attackers know that the party will be over soon and so they're going to maximize their return on investment in their research to find exploitable vulnerabilities.

Microsoft also saw similar spikes in attacks after announcing coming changes to Microsoft Office file formats meant to halt attacks. While Adobe didn't do a full scale security push, the company did also announce security improvements and saw similar increases in attacks after that.

Based on this, we can expect that there's a good chance for increased attacks against Java until the improved Java code is out there and widely deployed.

Get Ready for Things to Break

The next important lesson comes from the Windows XP SP2 experience. The service pack introduced major improvements. But we have to remember at the time it came out, the cost was high. Microsoft disabled features by default and turned security features that could be intrusive on for the first time. For example, the Windows Internet Connection Firewall shipped in Windows XP at launch, but was turned off by default. Windows XP SP2 turned it on by default. It was the right decision and was a major factor in eliminating Blaster and Slammer-type worms. But it caused applications to break and was costly for customers to deploy.

That was the most dramatic example but there were plenty of others. The key point is that when a company's posture towards a product shifts from prioritizing features and functionality above all to including security as a priority, it requires a ratcheting down of the freedom that developers and users are used to with that product. For Java, we've already seen changes around how Java handles unsigned or self-signed applets that will impact applets that are already out there. We can view this as the beginning of an ongoing process of security enhancements having an impact on existing applets and applications. Some things that worked fine on Java before will quit working and require retooling.

Not Everyone Will Be Made Safer

This relates to the problem of app compatibility (i.e. things breaking): because of the dramatic nature of changes, not everyone will be able to use those newer versions with the security improvements. Legacy applications and applets that simply can't be updated and can't be discarded will force some organizations and people to stay on older, less secure and no longer serviced versions of Java. Unfortunately, these people will form a ready pool of potential victims for attackers. In many cases, these people will be subject to multiple attacks at various points in time. A look at malware infection rates on both sides of the Windows XP SP2 line show that people on Windows XP Gold and SP1 were subject to significantly more malware on their systems.

The question of resistance to adoption was always a hard one at Microsoft. We know that the significant changes in Windows XP SP2 kept some people from upgrading. Piracy was another factor. User education and lack of awareness were still others.

Java will face all of these factors (except maybe piracy) as barriers to adopting new, more secure versions. Java will also face a hurdle that Windows generally didn't: it may be impossible to upgrade Java in some places. Java's cross-platform openness is its Achilles Heel here: software embedded in systems and devices often has no upgrade or update capabilities. And even where that capability does exist, the user may have no clue how to update.

All of this means that even with major improvements to Java, there will still be millions of systems and devices that will be left behind and so subject to attack.

Attackers Will Move On to Something Else

At the height of security problems at Microsoft, we always said that when security in Windows improved we would see the people attacking Windows move on to other targets. Within the industry we know well that attackers focus on the easy targets and move on as targets harden. It's the truth of the old saw "You don't have to be faster than the bear, just faster than the other guy". As Windows and IE became harder to attack, we saw attackers move to Office file formats. As those were hardened, they moved on to Adobe Acrobat and Flash.

Part of what we've been seeing with Java is that it's the latest soft target in the cross hairs. It's not like Java security deteriorated suddenly: these problems have always been there, they just haven't been exploited. Attackers have moved to Java because other targets (notably Adobe Acrobat) have gotten harder to exploit. Java's cross-platform nature also makes it more attractive in this post-PC world (giving truth to the joke we use to make about Java of "write once, patch everywhere").

In time as Oracle's improvements take root, Java will be less attractive and attackers will look for the next big thing. This is where the rest of the industry needs to pay attention, watch for early signs of the next target, and move quickly to meet those attacks. We can't know who will be next up, but it's a safe bet that attackers will continue to focus on multi-platform technologies in this post-PC world.

Of course, the best defense is a good offense and the best thing that others can do is to follow Oracle and Microsoft's lead and do their own security push NOW before they become a target. Unfortunately that likely won't happen: we've seen that when a vendor is under the gun like this, the industry likes to criticize and watch with schadenfreude. But there's very little movement to recognize these issues as the latest manifestation of an industry problem and address it as an industry.

For myself, until we start to see the results of Oracle's push, I've got Java disabled. But I fully expect and look forward to using it once again. Based on my experience with Microsoft, I have confidence that Java will join Windows as being one of the best things out there from a security point of view. I'm glad to see someone following Microsoft's lead and look forward to who chooses to follow next.

Photo Credit: pryzmat/Shutterstock

Christopher Budd is a communications manager at Trend Micro. He is a 10-year veteran of Microsoft, where he oversaw and managed communications around online security and privacy incidents. He left the company in December 2010. Today uses his experience in the areas of threats to online security and privacy, crisis communications, and social media to help people better protect themselves.

3 Responses to Microsoft's experience shows us what to expect from Oracle's Java 'security push'

© 1998-2024 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.