Sun needs to revise their update strategies
Aug 17th, 2008 by Micheal
As the creator of the Java programming language, Sun is responsible for maintaining updates to the language and the interpreter and compiler. However, their current update strategy leaves customers at risk even after they have updated.
As you may or may not be aware, Blackhat 2008 just happened. One of the things to come from that conference was research dubbed “GIFAR.” For those who haven’t been following things, this basically masks a Java JAR file inside a GIF, JPEG, and a variety of other formats such as DOC. GIFs (and other image formats) are typically trusted by web applications, but following this attack, attackers can stuff in Java-based exploits, like the old ByteVerify and have users run the code in the context of the website the image-applet was uploaded to. This means they bypass the SOP, or Same Origin Policy. I discussed this in a previous post. Now attackers can use XSS, CSRF, and a variety of other fun things.
Let me be clear: This is a Java issue, and not a web application issue.
Now here comes the problem. Sun, for whatever the reason, installs updates as new versions, meaning old versions are left behind. This has been done and known for quite some time, and I’m sure many a debate have started over this. This is just another nail in Sun’s coffin. Sun is going to be releasing a patch for this. It will be pushed out, and users will update eventually (the process leaves much to be desired, as I have somehow managed to skip a couple of versions in the past without being notified I was out-of-date). However, it is possible for the applet HTML tag to request an older version if it is on the system, bypassing completely the patch that Sun has released.
It could be argued that Sun does this for the enterprise (which Sun does, apparently). However, Sun needs to at least notify users that older versions were left behind and give them the opportunity to remove the older, more vulnerable versions. Most users don’t want the older versions on their systems, and don’t worry about breaking things.
How do I fix this, you ask? I was pointed to software called JavaRa. After a brief run-through, the software seems to do its job of finding and removing old Java versions. It offers other functionality, such as finding updates to Java, and various advanced features. The update function didn’t seem to quite work for me, so I’ll play with it and see if I can find out why. I didn’t try the advanced features.
So that’s why I say Sun needs to revise their strategies. They aren’t doing their users any favors by leaving old versions behind where most users don’t know they are there. I even forget from time to time. Don’t worry, I do still uninstall old versions. 
My point is though, something needs to change. ByteVerify is still affecting people, partly because of this problem of leaving old Java versions behind.