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!

On Thursday (Apr 4) Microsoft announced the forthcoming content for Patch Tuesday – Apr 9, 2013.


You can have Microsoft's security bulletins sent directly to you:

To receive automatic notifications whenever Microsoft Security Bulletins are issued, subscribe to Microsoft Technical Security Notifications.


Microsoft also hosts a webcast where they discuss the releases, typically the Wednesday after Patch Tuesday:

Microsoft will host a webcast to address customer questions on the security bulletins on April 10, 2013, at 11:00 AM Pacific Time (US & Canada).

Register now for the April Security Bulletin Webcast. After this date, this webcast is available on-demand.


You can also follow the MSRC team at @MSFTSecResponse.

 

Number of Releases: 9

Critical Security Updates: 2 addressing vulnerabilities in Windows and Internet Explorer.

Important Security Updates: 7 addressing vulnerabilities in Windows, InfoPath 2010, Sharepoint Server 2010/2013, Sharepoint Foundation 2010, Groove Server 2010, Office Web Apps 2010, and Windows Defender for Win8/WinRT.


Updates are typically released by Microsoft at 10am PT (6pm UTC).

Configuring WSUS servers to synchronize relative to that time can be helpful in expediting availability of these security updates.

Configuring the Windows Update Agent - Overview

Configuring the Windows Update Agent - General Settings Part 1

Configuring the Windows Update Agent - General Settings Part 2

Configuring the Windows Update Agent - WSUS Settings

 

7. WUA Policies related to scheduled installations only

A number of settings are related explicitly, and exclusively, to scheduled installations. For these settings, a scheduled installation is an installation initiated by the WUAgent when AUOption=’4’ at the ScheduledInstallationDay and ScheduledInstallationTime specified in the settings. Any other installation is considered an unscheduled installation and these settings are not relevant.

 

Delay Restart for Scheduled Installations

This setting allows the configuration of how long the WUAgent waits after the completion of the installation event before launching the restart sequence. Generally this option would only have significance when installations are scheduled to occur during the workday and the user may be impacted. The default value is 5 minutes. It can be set from 1 to 30 minutes.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

RebootWarningTimeoutEnabled

0-1

0x0–0x1

If enabled, uses the delay specified in the RebootWarningTimeout value

RebootWarningTimeout

1-30

0x1–0x1e

 

Delay Restart for Scheduled Installations - Registry.pngDelay Restart for Scheduled Installations - Policy.png

 

No Auto-Restart with Logged On Users for Scheduled Automatic Updates Installations

When a scheduled installation occurs with a logged on non-administrative user on Windows XP (or Windows Server 2003), that user will be forced to restart the system. This setting allows the non-administrative user to interactively launch the installation, rather than it occurring automatically. It does not grant the non-administrative user the ability to defer or cancel the restart. Admin users always have the option to initiate or defer the restart. Generally this option would only be used for scheduled installation events that occur during the workday. Enabling this option with overnight scheduled installations can interfere with the expected system restart if a user failed to log off of the system at the end of the workday. All users on Vista and newer systems are prompted with a dialog to control when the restart occurs, unless the setting to block this functionality has been enabled. On Vista and newer systems, the user is given three choices when deferring the restart: 10 minutes, 1 hour, or 4 hours. This setting has no functional significance on Vista and newer systems.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

NoAutoRebootWithLoggedOnUsers

0-1

0x0–0x1

If enabled, allows a non-admin user to initiate the restart, rather than having it forced by the WUAgent

No Auto-Restart with Logged On User - Registry.pngNo Auto-Restart with Logged On User - Policy.png

Re-prompt for Restart with Scheduled Installations

When a user on Windows XP/2003 is presented the option to “Reboot Later,” the duration of the delay before the user is prompted again is determined by this setting. The default delay is 10 minutes. The delay can be configured from 1 to 1440 minutes (24 hours). On Vista and newer systems, the delay is selected by the user from one of three choices: 10 minutes, 1 hour, or 4 hours.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

RebootRelaunchTimeoutEnabled

0-1

0x0 – 0x1

If enabled, allows the configuration of the time delay before the restart dialog is presented to the user

RebootRelaunchTimeout

1-1440

0x1 – 0x5a0

 

Re-prompt for Restart With Scheduled Installation - Registry.pngRe-prompt for Restart With Scheduled Installation - Policy.png

 

Reschedule Automatic Updates scheduled installations

This setting determines whether updates are installed at system startup when the scheduled installation event is missed and how long the delay after startup is before installation begins. The default behavior is to install updates 1 minute after startup (as a matter of practicality, this is 1 minute after the Windows Updates service startup). The installation at startup can be disabled, or it can be configured to occur from 1 to 60 minutes after startup.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

RescheduleWaitTimeEnabled

0-1

0x0 – 0x1

If enabled, allows the configuration of the time delay after restart; If disabled, installation at startup will not occur

RescheduleWaitTime

1-60

0x1 – 0x3c

 

Reschedule Automatic Updates Scheduled Installations - Registry.pngReschedule Automatic Updates Scheduled Installations - Policy.png

 

Enable Windows Update Power Management to automatically wake up the system to install scheduled updates

For systems that are in sleep or hibernation mode, this setting allows the system to wake up at the scheduled installation event to install updates. If deadlines are configured, and expire, the system will wake up when the deadline expires. If the system is running on battery power, it will be returned to hibernation.

 

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Registry Value

Valid Decimal Values

Valid Hex Values

Notes

AUPowerManagement

0-1

0x0 – 0x1

If enabled, allows the system to wake up to install updates.

Enable Windows Update Power Management - Registry.pngEnable Windows Update Power Management - Policy.png

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.