Sun have just released JRE Version 6 Update 7… which means 90% of desktops are currently at risk until they are upgraded!*. If you have the Java Update Scheduler enabled you should get prompted to update soon (depending on the update frequency you selected). If you want to be proactive, fire up the Java Control Panel, click on the Update tab then click on the Update Now button or head to http://www.java.com and download the binary directly.
According to Sun’s Security Blog the latest update fixes 8 issues. I’ll be releasing advisories and blogging on the issues that I had a hand in, namely:
- 238666 Native code execution through malformed TrueType font headers in untrusted Java applet.
- 238905 Multiple buffer overflows in Java Web Start JNLP handling
- 238905 Security problems with the JRE family version support
If you’re thinking the first two issues sound all too familiar, you’d be right. I previously discussed this font issue that led to execution of arbitrary code. And the JNLP parsing code has had a number of similar buffer overflows (details here, here and here) … not so much “same bug, different app” (the theme of this Brett Moore presentation) as “same bug, same app!”
So perhaps the most interesting vulnerability is 238905, the JRE family version support issue. You may have noticed that JRE updates typically install alongside older versions so a given machine is likely to have several versions installed as noted by Brian Krebs. Prior to the introduction of Secure Static Versioning in JRE Version 5 update 6, it was possible for an applet to select the version of the JRE with which to run. Of course, a malicious applet could purposefully select an older vulnerable version in order to exploit known security flaws. Secure Static Versioning fixed this, however during my tests I was able to circumvent it and downgrade the browser’s JRE. More on this in a future post.
I’ll also be blogging on a couple of other issues Sun have recently fixed. There are no SunSolve entries for these since they turned out to be flaws in the interaction between Java Web Start and Sun’s web servers when installing alternate versions of the JRE as specified in JNLP files. They ultimately allowed us to present bogus security dialogs to the user, duping them into installing an older version of the JRE. These issues serve as a reminder of the dangers of including user-supplied input in security-related dialog boxes.
So a few things in the pipeline; I haven’t forgotten about part II of Stealing Password Hashes with Java and IE but it’s a busy time and Black Hat is almost upon us so be patient 🙂
*** This is a Security Bloggers Network syndicated blog from aut disce, aut discede authored by John Heasman. Read the original post at: http://heasman.blogspot.com/2008/07/time-to-update-your-jre-again.html