Article 1692 of comp.lang.java.security:
In message <32B88449.10F2@dialogosweb.com>
        Jeff Nelson <jnelson@dialogosweb.com> writes: 

> John Wilson wrote:
> > 
> > The JDK 1.1 Beta 2 compiler does not object to the following code:
> > 
> > class C {
> >     public C (Object x) { o = x; };
> > 
> >     public Object o;
> > }
> > 
> > class D extends C {
> >     public D() {
> >         super (new Object() {
> >             {
> >                 C.this.o.getClass();
> >             }
> >         });
> >     }
> > }
> > 
> > However the code "C.this.o.getClass();" makes access to o before the
> > instance of the class is fully initialized. This seems to me to be a
> > possible security hole.

> Could you discuss in more detail how this represents a security hole? 

Apologies in advance for any errors - I haven't tried to compile this:

// C.java
public class C { // should not be instantiated by applets
    public C() {
        SecurityManager s = System.getSecurityManager();
        if (s != null) s.checkCreateC();
    }
    protected native hoseSecurity();
}

// MyApplet.java
class D extends C {
    D() {
        super (new Object() {
            {
                C.this.hoseSecurity();
            }
        });
    }
}

public class MyApplet {
    void init() { new D(); }
}

Here the applet calls a method in a class that it is not supposed to be able to
instantiate. Fortunately, there are no classes like C that rely on 
this technique
for preventing access any more (or at least, there are not supposed to be).

(Incidentally, I'm not revealing any new information here; something 
very similar
was discussed on clj.security or comp.lang.java a few months back).

David Hopwood
david.hopwood@lmh.ox.ac.uk, hopwood@lmh.ox.ac.uk