Pack200 is a compression method introduced by Sun in the 1.5 release of the JRE. It is used to compress JAR files, and is optimized for the compression of Java class files. A Java applet can be compressed using the pack200 tool, and if the browser plugin supports the pack200-gzip encoding it will pass the compressed JAR file to the JRE for unpacking. For more information, see the vendor's site at the following links.
Remote exploitation of an integer overflow vulnerability in Sun Microsystems Inc.'s Java Runtime Environment (JRE) could allow an attacker to execute arbitrary code with the privileges of the current user.
The vulnerability occurs during decompression when, to calculate the size of a heap buffer, the code manipulates several integers in the file. The bounds of these values are not checked, and the arithmetic operations can overflow. This results in an undersized buffer being allocated, which leads to a heap-based buffer overflow.
This vulnerability is similar to a previous iDefense vulnerability in the JRE Pack200 code, and is due to an incomplete fix of the previous vulnerability.
Exploitation allows attackers to execute arbitrary code in the context of the currently logged-on user. To exploit this vulnerability, a targeted user must load a malicious Web page created by an attacker. An attacker typically accomplishes this via social engineering or injecting content into compromised, trusted sites.
Exploitation of heap-overflow vulnerabilities on modern operating systems can, at times, be difficult due to various heap integrity protections; however, the Pack200 code uses a custom allocator that does not contain such integrity checks. Labs testing has demonstrated that code execution is possible on the Linux platform. A similar methodology is likely to be successful on the Windows platform.
iDefense has confirmed the existence of this vulnerability in Sun Microsystem Inc.'s JRE version 1.6.0_11 for Windows and Linux. According to Sun, Pack200 was first introduced to JRE 1.5.0. The latest version of JRE 1.5, 1.5.0_15, does contain the vulnerable code, but the browser plugin does not handle Pack200 encoding. As such, exploitation through the browser does not appear to be possible with JRE 1.5. This vulnerability is different than the previously reported iDefense issue with the Pack200 code.
Sun Microsystems reports that the vulnerability can occur in the following Java SE and Java SE for Business releases for Windows, Solaris, and Linux:
* JDK and JRE 5.0 Update 17 and earlier * JDK and JRE 6 Update 12 and earlier
Note: SDK and JRE 1.4.2 and 1.3.1 are not affected by this issue.
The library containing the vulnerability can be renamed, which will prevent it from being loaded. This workaround will prevent users from loading Pack200 format JAR files, and from using the pack/unpack tools that come with the JRE; however, normal applets and Java applications will continue to function correctly. The vulnerable library is called "unpack" and can be found in:
"%SYSTEMDRIVE%Program FilesJavaJAVA VERSIONbinunpack.dll"
on Windows and in differing locations, dependent upon the distribution/platform on Unix systems.
Sun Microsystem Inc. has released a patch which addresses this issue. For more information, consult their advisory at the following URL:
A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not been assigned yet.
01/09/2009 - Initial Contact
01/22/2009 - requested PoC
01/22/2009 - sent PoC
01/31/2009 - Vendor acknowledged PoC
02/05/2009 - Requested CVE from vendor
03/25/2009 - Coordinated Public Disclosure
This vulnerability was reported to iDefense by regenrecht.
Get paid for vulnerability research
Free tools, research and upcoming events
Copyright © 2009 Verisign, Inc.
Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail customer service for permission.
Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.