Java 6 update 26 is out

Blog Update: I mapped some of the CVEs to these results.


Oracle has released a security update for Java. If you have Java installed and haven't updated your Java yet, do it now. I'll wait.

No, really. I'm not going on until you do.

...

OK, great. Now, I'm going to try something new and analyze the differences between Java 6 update 25 and Java 6 update 26. And we'll try to figure out what the underlying vulnerability might have been.

For the comparison, I'll be using my rather stale open source project reJ/rejava. You feed it two .jars and it does a binary comparison of each of the files in the .jar, and indicates which files are new, removed, or changed. It then allows you to open these changed files and it does another diff on method level, and yet another on the bytecode level of each changed method. It works OK, sometimes the algorithm consumes all the memory available, though.

Let's get started:

File: rt.jar (the runtime - heart and soul of Java):

Package: sun.util.resources
TimeZoneNames
TimeZoneNames_de
TimeZoneNames_es
TimeZoneNames_fr
TimeZoneNames_it
TimeZoneNames_pt_BR
TimeZoneNames_sv

These are not security related, just updating the time zone data. OK, I got curious. rej chokes on these files, because they're big. It seems the change is more or less the same as this:

http://hg.openjdk.java.net/jdk7/build/jdk/rev/55f97ad0a36e

Namely the addition of America/Metlakatla and America/Sitka


Package: sun.misc
Version

Also not security related. Updated the version strings to update 26.


Package: sun.java2d.pipe
DrawImage

Not security related. The line numbers have changed, maybe a comment added to the code. I'm compaing the rt.jar from the JDK which has debugging information (like source-code line number information) included.


Package: javax.swing
ImageIcon

This is security related. But from a quick look, I can't figure out what the vulnerability is. The source for this class is available in the src.zip of the JDK for both versions. The ImageIcon has a static protected component field whose appContext field is set to null in a privileged block. In the new version this component is instantiated in another doPrivileged block which removes all it's permissions.

It was found that the MediaTracker implementation created Component instances with unnecessary access privileges. A remote attacker could use this flaw to elevate their privileges by utilizing an untrusted applet or application that uses Swing. (CVE-2011-0871)

Package: java.security
SignedObject

This looks security related as well. Also available in the src.zip. SignedObject's readObject method has been updated. The update 25 version looked like this:
s.defaultReadObject();
content = (byte[])content.clone();
signature = (byte[])signature.clone();

and the update 26 looks like this:

java.io.ObjectInputStream.GetField fields = s.readFields();
content = ((byte[])fields.get("content", null)).clone();
signature = ((byte[])fields.get("signature", null)).clone();
thealgorithm = (String)fields.get("thealgorithm", null);

This might be related to the problems of serialization I wrote about. In the old version you could deserialize a SignedObject and get a reference to it, and the internal byte arrays for content and signature and pause the deserialization process before the two fields were replaced by clone().

A flaw was found in the way signed objects were deserialized. If trusted and untrusted code were running in the same Java Virtual Machine (JVM), and both were deserializing the same signed object, the untrusted code could modify said object by using this flaw to bypass the validation checks on signed objects. (CVE-2011-0865)

Package: java.net
NetworkInterface

This a fix to the NetworkInterface.toString() method spilling out IP addresses, etc that I presented as an example of Trusted Method Chaining at the t2 infosec conference in 2010 and blogged about earlier this year. Kudos to Oracle for reading my blog. Now the toString() method doesn't return IP addresses anymore.

An information leak flaw was found in the NetworkInterface class. An untrusted applet or application could use this flaw to access information about available network interfaces that should only be available to privileged code. (CVE-2011-0867)

Package: com.sun.xml.internal.messaging.saaj.client.p2p
HttpSOAPConnection

This is a fix to another slight issue I talked about at the t2 infosec conference, the HttpSOAPConnection class used to do HTTP requests that violated the same origin policy. That has been fixed. And as a bonus, this class used to set system proxy settings, which I hadn't mentioned anywhere, but which was on my TODO list. I guess I can remove it now. I didn't blog about that, so I guess that means Oracle also looked at my presentation slides. Nice.

It was found that untrusted applets and applications could misuse a SOAP connection to incorrectly set global HTTP proxy settings instead of setting them in a local scope. This flaw could be used to intercept HTTP requests. (CVE-2011-0869)

Package: com.sun.org.apache.bcel.internal.classfile
Utility

OK, you guessed right. This fixes yet another issue I talked about at the t2 infosec conference, and blogged about here. That is, this class which seems to originate from the BCEL project, had some funky logic which lead to a System.exit(), if instrumented in the right way. The System.exit() has been removed.


File: plugin.jar (as the name suggests, this has Java plugin specific stuff)

No changes.


File: resources.jar

No changes.


File: jsse.jar (Java Secure Socket Extension)

No changes.


File: jce.jar (Java Cryptography extension)

No changes.


File: javaws.jar (Java Web Start)

No changes.


File: deploy.jar

Package: com.sun.deploy.config
Config

There's a binary difference, but reJ doesn't detect any bytecode differences. I'm guessing this is another linenumber difference.


Package: com.sun.deploy.util
JVMParameters
SecurityBaseline
URLUtil

SecurityBaseline has version information which has been updated.

JVMParameters has a change that has something to do with verifying if a Parameter is secure, but I can't figure out what's the net effect here. This seems to be clearly security related, but I can't figure out how severe. Update: I'm guessing this might be related to: ZDI-11-192 by Chris Ries.

URLUtil has a change in the checkTargetURL method which that deals with jar and file URLs. This also seems to be clearly security related, but I can't figure out how severe.

Update: As pointed out in the comments, this seems to be the fix for non-security bug, Bug ID 7020709. Thanks @mihi42!


File: charsets.jar

No changes.


File: sunpkcs11.jar

Package: sun.security.pkcs11
Config
ConfigurationException
P11Cipher
Secmod

Config and Secmod seem to have real changes, but I'm not familiar enough with the pkcs packages to quickly assess what's going on.

By my counts that means that the majority of the fixed issues are in the native side, which I won't be dealing with here.

Inflated Java Malware Infection Rates

In the past year or so, I've read many articles on Java malware (most recently Gregg Keizer's article at Computer World and Dustin's blogpost at "Inspired by Actual Events" ). The fact that many of the top offenders are based on vulnerabilities I've found (CVE-2008-5353, CVE-2010-0840, CVE-2010-0094) makes me wince every time I read one of these (I don't consider myself to be one of the bad guys just because I like to break things).

None of the articles pointed out one important thing that might very well be distorting Java malware infection rates, and it's this: The fact that Microsoft Security Essentials, or any other Anti-virus correctly identified the presence of a malicious piece of Java code on a user's machine does not mean that user was infected. Infection might not even be likely.

The way Java works with Applets is that when there's an applet tag on a page, Java downloads the relevant code and saves it in the Java cache (...\username\Application Data\Sun\Java\Deployment\cache). The code is then executed from disk. If your Java is up-to-date, CVE-2008-5353, CVE-2010-0840, CVE-2010-0094 all fail to execute, resulting in a SecurityException. But the offending code will remain in the cache and Security Essentials will find it and report it. It will inflate the statistics.

I verified this on a Windows XP with the latest Java (Java 6 update 25), executing the CVE-2008-5353 Applet from Metasploit, which is detected by Security Essentials. As the Java is up-to-date, the exploit never executed. Nevertheless Security Essentials correctly identified CVE-2008-5353.

In conclusion, I do recognize that Java is notoriously badly updated by a big part of the user base and we wouldn't see tons of Java malware if some of it wasn't successful, but I think the Java malware infection rates are inflated by cases where users have malware in their cache that was never able to escape the sandbox of an updated Java.