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.

How to Fix Firefox and Chrome Default of Retaining Session Cookies Insecurely

On last week’s episode of the Security Now podcast (Listener Feedback #147, transcript at, listener Anthony in Melbourne, Australia informed Steve Gibson and the world of a surprising fact. Of the three major browsers, only Internet Explorer respects session cookies properly. By respects, I mean that any web site session cookie should only reside in transient memory and not be persisted to your hard drive.

It appears that for a while now, both Firefox and Chrome have, for the convenience of their users, restored session cookies between browser shut down and restart. This is convenient, but insecure. Only persistent cookies should restore in this way. A common example of the usage of persistent cookies is when you check “keep me logged in” or “remember me” when logging into a site.

Neither Mozilla nor Google seem inclined to revert to the correct secure behavior that IE has kept. If you really love using their browsers (like me), but want to fix this, I’ve given the steps below.


As discussed on the podcast, the way to get the correct secure behavior back in Firefox is to browse to about:config, enter ‘sessionstore’ in the search box, and change browser.sessionstore.privacy_level from 0 to 2.



I had to dig around for this one. It seems from the discussion at that the session cookie-restoring behavior is only in the case where “Continue where I left off” is selected in Chrome’s settings. Note in the picture below, I did not have this set:


Make sure “Continue where I left off” is not selected in your browser either. In addition (from Browse to chrome://flags, Press CTRL-F and enter ‘disable better’ to jump to the “Disable Better session restore” flag. Enable it.