About 3 months ago we took an in-depth look at the state of Java with respect to the number of reported/fixed vulnerabilities, and how that impacted earlier versions of Java. Since that time, three additional Java security updates have been released, plus some very interesting research has been published on what versions of Java are still in use. We're going to cover both of those in this update.

 

Recap

Let's start by adding the vulnerability counts for the three most recent updates. To recap, after the release of JRE7u13, which was almost entirely a patch for historical vulnerabilities (only 6 of the 39 fixes applied to JRE7-only vulnerabilities), research showed that over 80% of the reported/fixed vulnerabilities in JRE7 previously existed in JRE6, and almost half of them existed in JRE5:

JRE7u13 vulnerability counts.png

 

JRE7u21

Since that time, another 49 vulnerabilities have been patched -- 42 of them in JRE7u21, which was released just last week. Of those 49, 29 of them also existed in JRE6 (59.2%), and 21 of them existed in JRE5 (42.8%).

 

This brings the total counts for all of the security vulnerabilities identifed in JRE7 up to 172, with 128 (74.4%) present in JRE6, and 82 (47.7%) present in JRE5.

JRE7 total vulnerabilities (thru JRE7u21).png

So, let me say this as loudly and clearly as I can.... it is **NOT** safer to keep running Java 6 or Java 5. If you need to have the Java Runtime Environment installed, then you **NEED** to upgrade to JRE7 immediately, and uninstall any earlier versions of the Java Runtime Environment.

 

Sadly, as recently published research shows, it seems that very few are actually getting that message.

 

Who's not running JRE7?

Recently, Websense added Java version detection capabilities to their Advanced Classification Engine (ACE™) and pushed it through the Websense ThreatSeeker® Network to get real-time information about what versions of Java were in use. A month ago they published their findings. This analysis includes data from TENS of MILLIONS of users, so don't consider this a "representative sample"... this is the Real World folks, and you're quite likely part of it.

 

You can view the multi-colored rainbow-moired pie-chart -or- read the entire article but let me share some of the scariest numbers with you:

  • 8.7% of those tens of millions (that's almost a million browsers), still have versions prior to JRE5 installed. (More on this below!)
  • 2.5% are still using JRE5 (about a quarter million)
  • 3.7% are still using JRE6u7 -- the last version released that was not automatically uninstalled with a patch upgrade
  • 66.4% of browsers are running some variant of JRE6
  • 22.4% have upgraded to JRE7, but only 5.2% were using the current patch level of JRE7 (7u17 at the time of the study)

 

That's over ten million (at least!) systems running an instance of the JRE with known vulnerabilities that are being actively exploited. Websense also notes that "the largest single exploited vulnerability is the most recent one" -- one of the two fixed in JRE7u17! (and also present in JRE6u41 and earlier).

 

JRE5???

What about these million systems actively using a version of JRE prior to 5? Where did they come from? To first grasp this we need to call attention to the fact that JRE5 was originally released in September, 2004. So, by definition, this group includes a lot of Windows XP machines, and even scarier, probably some machines older than Windows XP. It's remotely possible that some of these systems are Windows 2000 or Win9x systems running the Microsoft Java Virtual Machine (JVM) which was based on Java v1.1. One thing I can tell you for certain -- they're probably infested, and most likely are part of a botnet. But consider this ... the data came through Websense, which means the machines are sitting behind a Websense appliance! These are not home systems (well, unless their ISP is running Websense appliances on the front-end) ... these are corporate, governmental, and organizational systems!

 

You need a JRE patching strategy!

Here are some questions to consider in your JRE patching strategy:

  • Have you validated the need to have the JRE installed, and uninstalled it from machines where it is not needed?
  • On the systems where it is needed, have you upgraded to JRE7?
  • On your JRE7 systems, do you have a patch management strategy in place to ensure the latest version of JRE7 is installed?

 

Software Vendors and JRE "compatiblity"

Finally, something I hear a lot -- "My vendor says their software won't work with newer versions of JRE."

 

For those systems where another software vendor claims compatibility issues with newer versions of the JRE:

  • Have you verified that the vendor is not just blowing smoke up your nose because they haven't tested their software against the newest versions of JRE and certified compatibility?
  • What value is "support" from a vendor that can't even keep up with the latest security guidance?
  • Is your network's security and your organization's ability to continue to operate, more important than following the guidance of a software vendor that can't be bothered?

 

Do your own testing!! If it works, then upgrade the JRE, be secure, and then go hold that vendor's feet to the fire for doing the same. Do not let your organization be held hostage to critical security risks by a non-responsive software vendor!

 

There are ten million PLUS systems on the Internet *today* running a version of Java that is known to have active exploits. Do not be part of the problem ... be part of the SOLUTION!