Security Explorations Says More Critical Java Vulnerabilities Left Unpatched in Latest Update

In a new article in the Register (, subtitled Emergency fix rushed out half-baked, author Neil McCallister is just a little too alarmist. The only bit of new information here is that, of the 31 vulnerabilities that Security Explorations notified Oracle of in April, there are at least 2 more unpatched that the security firm considers critical. By critical, I mean code being able to bypass the Java security sandbox.

Almost buried in the article is that these vulnerabilities are not zero-day vulnerabilities, i.e., there are no known exploits in the wild yet. I don’t think Oracle is under any obligation to get these patched immediately as long as the white hats have all kept the details under wraps. It would be nice if they did patch them, but who knows how many other critical vulnerabilities they are working on fixes for?

In fairness, this situation is the counter-argument to my conclusion in my previous blog post that quarterly scheduled updates are probably fine. Knowing that these vulnerabilities exists makes me wish that there was a monthly update, hopefully including the fix for these, coming up in September, rather than a quarterly one in October.

Oracle Quickly Patches Latest Zero-Day. Would a Monthly Update Schedule Have Helped?

Less than a week after the announcement of a new zero-day vulnerability affecting Java 7 (see and, Oracle has released a fix in the form of Java 7 Update 7:

Perhaps this is not too surprising, given that Polish security firm Security Expectations claims to have notified Oracle of the vulnerability (which is actually 2 vulnerabilities combined) earlier this year in April (see Now the details of who knew what, and when, are very interesting, but that is not what I wish to write about here.

I want to consider if this would have played out much different if Oracle had changed their stance that a quarterly update schedule is sufficient, to adopting a more Microsoftian monthly update schedule. Here are the approximate relevant dates:

  • 2012-Apr-02: Security Expectations reports vulnerabilities to Oracle.
  • 2012-Apr-17: Scheduled Oracle Update (Java 7 Update 5). See for schedule details.
  • 2012-Jul-17: Most recent scheduled Oracle Update (Java 7 Update 6).
  • 2012-Aug-26: Reports emerge of exploits found in the wild of the latest zero day vulnerability CVE-2012-4681.
  • 2012-Aug-30: Out of band security patch (Java 7 Update 7).
  • 2012-Oct-16: Next scheduled Oracle Update

So, not one, but two scheduled updates went by without these particular vulnerabilities patched. However, by their own accounting, Oracle patched 175 vulnerabilities in these two releases. In such a widely exposed product as Java, which represents a very large number of lines of code, vulnerability reports must come in almost every day.

In fact, Oracle’s number gives about 1 vulnerability being fixed per day. In addition, Oracle, like Microsoft, is under pressure from the marketplace to keep innovating and adding features to their flagship products. Any experienced developer will tell  you that new code inevitably brings new bugs, including security vulnerabilities.

Suppose Oracle were releasing monthly patches, and had the opportunity to push out another 30 or so fixes by, say, August 14 (the Tuesday closest to the 17th). Without knowing there were exploits brewing in the wild for this particular pair of vulnerabilities, they have to prioritize based on where they think the software is most vulnerable. There is a non-zero likelihood of being wrong in that assessment.

So, while I have been in agreement with much of the community that a monthly patch cycle would be an improvement for customer security, I can’t argue strongly that it would have helped in this case.