Re: Huge security hole in Sun's JVM

Jeff Nisewanger (jeff.nisewanger@eng.sun.com)
Sat, 8 May 1999 17:13:11 -0700 (PDT)

Message-Id: <199905090015.RAA00976@shorter.eng.sun.com>
Date: Sat, 8 May 1999 17:13:11 -0700 (PDT)
From: Jeff Nisewanger <jeff.nisewanger@eng.sun.com>
Subject: Re: Huge security hole in Sun's JVM
To: pugh@cs.umd.edu

> > This is not a bug. What you are seeing is that in some
> >circumstances Java classes are purposefully not run through full
> >language access control checks when loaded directly from the local
> >disk. Illegal accesses by downloaded Java code will be caught.
>
>
> Sorry, but I believe it is a bug.
>
> My reading of the spec is that in Java 1.2, all non-core classes are verified.
> The spec doesn't say anything about hacks for bugs in the java 1.1.2 compiler.
>
The behavior you see is an intentional backwards compatibility
workaround for existing applications which run on JDK 1.1.x so that
they may continue to run on JDK1.2. This is because classes loaded from
the class path in 1.1.x are not subject to language-level access checks
during resolution.

Bytecode verification is one stage of linking as described in
the Java VM specification, 2nd Edition, section 2.17.3. Symbolic
resolution is another stage of linking and performs the language-level
access checks. Classes on the application class path in 1.2.x are now
generally subject to language-level access checks during symbolic
resolution except for the single limited workaround that I described in
my previous reply.

The workaround does not introduce any significant security
issues since relaxed access checking is only allowed to other classes
from the application class path loaded by the same class loader and
which are in the same java.security.ProtectionDomain. Downloaded
classes are always subject to full access checking. All non-core
classes are always verified. I agree that this behavior should be
documented in the release notes. The fact that it is not documented is
an oversight.

Jeff