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
scarybeasts@gmail.com