CESA-2009-005 - rev 1

[See all my vulnerabilities at http://scary.beasts.org/security]

[Blog if you want to subscribe to new findings is at http://scarybeastsecurity.blogspot.com/]

Sun Java JRE Pack200 memory errors

Programs affected: Sun JRE6 prior to update 13.
Severity: Unassessed. Possible compromise of client machine via evil applet.
Vendor URL: http://sunsolve.sun.com/search/document.do?assetkey=1-66-254570-1

A useful way to attack the Java runtime is to attack native code components it depends on. I've hit some of these: the 2d media libraries and ICC parsing. Others have taken the idea on and hit things like font parsing. Another piece of C parsing code is the "Pack200" support, so I thought I'd look at it (at about the same time as some other people, it seems)!

Here's a Java code sample demoing the Java API an applet could use to hit this native code:

import java.io.File;
import java.io.OutputStream;
import java.util.jar.JarOutputStream;
import java.util.jar.Pack200;

public final class Unpack {
  public static void main(String args[]) throws Exception {
    Pack200.Unpacker u = Pack200.newUnpacker();
    File f = new File(args[0]);
    OutputStream os = new OutputStream() {
      public void write(int b) {
    u.unpack(f, new JarOutputStream(os));
And some sample files you can feed into this to exhibit the crashes: bad.pack274, big.pack.0, smaller.pack.0, smaller.pack.3.

These files either cause crashes / trouble directly from within the JRE, or when passed into unpack200, e.g. unpack200 smaller.pack.0 /tmp/blah.jar.

These problems were found with a bit of fuzzing and do not represent a thorough source code audit.

CESA-2009-005 - rev 1
Chris Evans