Make sure you update that Java

Published: 2009-07-15
Last Updated: 2009-07-15 14:49:10 UTC
by Bojan Zdrnja (Version: 1)
3 comment(s)

One of our readers, Tom Ueltschi, sent an e-mail with details about an exploit that is exploiting a Java vulnerability. While such exploits are not rare, this particular exploit targeted a vulnerability that was published in December 2008 by iDefense, and a reliable exploit became publicly available couple of months ago, in April this year.

However, it took some time for the bad guys to start using this exploit in their attack kits. The vulnerability exists in Java JRE release 6, in update versions lower than 13 and release 5, update versions lower than 18.

The vulnerability exists in the Pack200 compression method, which is used to compress Jar files. The compression method is called when reading a Pack200 compressed file – the exploit creates an Applet which downloads a special crafted Pack200 compressed file. It's interesting how the attackers completely copied the publicly available exploit (they even used the same file names!), so they end up using an HTML file that creates the Applet, which further calls a PHP script called e.php that is needed to correctly set the Content-Encoding header:

<?php

$fp = fopen('e.pack.gz', 'rb');

header('Content-Encoding: pack200-gzip');

fpassthru($fp);
exit;

?>

The Applet contains shellcode, which gets executed if the vulnerability is successfully exploited – as you can guess it downloads a Trojan which, luckily, has *some* detection (VT link) with some major names still missing it.
After checking the malicious web site, it became obvious that the exploit has been integrated with an attack kit, so we can expect this to become more common now.

Finally, I'd like to remind every to double check that you have the latest Java installed on your machine (and those older versions removed). Also, don't forget about those nice addons such as NoScript which can limit your exposure by allowing Java or JavaScript to execute only on trusted web sites and not by default.

--
Bojan
 

Keywords: exploit java
3 comment(s)

Comments

What happens when you have application vendors that require you to use an old version of Java if you want them to support you? I know, I know--get another vendor. Well that's easy when you actually get to make that call, but when Marketing or HR has this software and they are not willing to change it just because some computer people say it is broken, what do you do? Those guys are in charge of making money and getting new talent in the door; upper management does not want to rock their boat. Rely on AV, IPS, Proxies, and FWs? Sadly, sometimes, that all you get.
Assuming you have good control over your workstations, what you do is:
* Install multiple versions of Java
* Yank all the SSV stuff that Sun wrote to try to fix the security holes that result from having multiple versions installed
* Develop expertise in managing all of the registry settings, creating appropriate CLSIDs, etc.
* Write a system that registers only the current version of Java for the gazillions of CLSIDs in existence. Have it run at boot or logon time.
* Write a system to allow the user to start the browser with an older version of Java - this rewrites all the CLSIDs and other registry settings to point to the older version, warns the user that they should only access that app, etc. When the browser closes, it should notice and automatically revert to the current version.

At least, that's what I would do. Of course this assumes an aggressively competent workstation administrator that is very comfortable writing scripts. If you're running your users without local admin privs (if you're not, you've got bigger problems than the above), you need some sort of SuDo-like system to allow those registry manipulation scripts to execute with elevated privs (or do all your manipulation in HKCU\Software\Classes, which takes precedence over HKLM\Software\Classes when the OS presents HKCR). I have similar support for the few machines that need to access a site that requires (puke) MS JVM. If you want to be really paranoid, write the system to automagically block ActiveX and Java for all websites except the specific known sites that need the older version when running with the older version enabled (this is all possible through appropriate on-the-fly registry manipulation by your local wizard).
@ Jason:

Both vulnerable versions dicussed in this article are still supported by Sun under the publically available security releases. For Java 1.4.2, you can BUY security updates for a VERY hefty price.

Diary Archives