Re: [SC-L] By default, the Verifier is disabled on .Net and Java

[Stephen de Vries <stephen () corsaire com>]

On 12 May 2006, at 09:10, Charles Miller wrote:
> It's not reflection: you're confusing IllegalAccessException and  
> IllegalAccessError.
>
> For any non-Java nerd still listening in: there are two fundamental  
> types of "Throwable" exception-conditions in Java: Exceptions and  
> Errors[1]. Exceptions represent application-level conditions --  
> things an application is likely to be able to recover from, like  
> network timeouts, trying to read beyond the end of a file, and so  
> on. Errors, on the other hand, represent VM-level problems that an  
> application can't really do anything about, like running out of  
> memory, not finding a required native library, or encountering  
> corrupted class files.
>
> IllegalAccessException happens when reflective code attempts to  
> access some field or method it's not supposed to. Because it's a  
> result of reflection, it's considered an application-level problem  
> and it's assumed your code can recover gracefully.
>
> Amusingly enough, you can get around most IllegalAccessExceptions  
> in java just by calling {field|method}.setAccessible(true). So long  
> as there's no explicit SecurityManager installed, as soon as you've  
> done that you're free to modify the field or call method to your  
> heart's content[2].
>
> IllegalAccess_Error_, on the other hand, happens when some non- 
> reflective code issues a bytecode instruction that attempts to  
> access a field or method it shouldn't be able to see. If you look  
> at its class hierarchy, the meaning of the class is pretty clear:  
> IllegalAccessError is a subclass of IncompatibleClassChangeError,  
> which is a subclass of LinkageError. Because this is a problem at  
> the bytecode/classloading level, and literally something that could  
> happen on _any_ method-call or field-access, it's flagged as an error.
>
> The Error generally occurs when class A has been compiled against a  
> version of class B where a method is public, but that method is  
> private in the version of the same class it encounters at runtime.  
> This sort of thing happens quite often in Java, you're frequently  
> stuck in "jar file hell", in a twisty turny maze of library  
> interdependencies, all with slightly different version numbers.
>
> More about the circumstances of IllegalAccessError here:
>
>    http://java.sun.com/docs/books/vmspec/2nd-edition/html/ 
> ConstantPool.doc.html
>
> Dynamic classloading isn't really at fault here. There are all  
> sorts of pits you can fall into when you start rolling your own  
> classloader (the Java webapp I develop supports dynamic runtime- 
> deployable plugins, and the classloading issues are a HUGE  
> headache), but IllegalAccessError isn't one of them.
>
> Charles
>
>    [1] Exceptions are further divided into checked exceptions and  
> runtime exceptions, but that's beyond the scope of this email
>    [2] See also: http://www.javaspecialists.co.za/archive/ 
> Issue014.html

Thanks for clearing this up Charles.
I've created another example that uses a class loader to load the  
classes, and this time, it throws an IllegalAccessError just like  
Tomcat does:

Loading class: /Users/stephen/data/dev/classloader/myclass/ 
somepackage/MyTest.class
Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/ 
Runnable.class
Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/ 
Object.class
Loading class: /Users/stephen/data/dev/classloader/myclass/ 
somepackage/MyData.class
Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/ 
System.class
Exception in thread "main" java.lang.IllegalAccessError: tried to  
access method somepackage.MyData.getName()Ljava/lang/String; from  
class somepackage.MyTest
        at somepackage.MyTest.run(MyTest.java:15)
        at classloader.Main.main(Main.java:26)
Java Result: 1

This error is thrown irrespective of the -verify flag.  So it looks  
like using a classloader causes the VM to perform verification,  
whether or not the "verifier" was enabled.  Michael Silk made a  
similar statement earlier in this thread.  Would you agree?

PoC code below:

package classloader;

public class Main {

    public Main() {
    }

    public static void main(String[] args) {
        //Illegal Access Error
        try {
            CustomLoader cl = new CustomLoader(System.getProperty 
("user.dir")+"/myclass/");
            Class myClass = cl.loadClass("somepackage.MyTest");
            Runnable r = (Runnable)myClass.newInstance();
            r.run();

        } catch (Exception e) {
            e.printStackTrace();
        }


    }

}


package classloader;

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;

public class CustomLoader extends ClassLoader {
    private String path = null;

    public CustomLoader(String path) {
        this.path = path;
    }


    private byte[] getBytes( String filename ) throws IOException {
        File file = new File( filename );
        long len = file.length();
        byte raw[] = new byte[(int)len];
        FileInputStream fin = new FileInputStream( file );
        int r = fin.read( raw );
        if (r != len)
            throw new IOException( "Can't read all, "+r+" != "+len );
        fin.close();
        return raw;
    }

    public Class loadClass( String name, boolean resolve )
    throws ClassNotFoundException {
        Class clas = null;
        String fileStub = name.replace( '.', '/' );
        String classFilename = path+fileStub+".class";
        System.out.println("Loading class: "+classFilename);
        File classFile = new File( classFilename );
        try {
            byte raw[] = getBytes( classFilename );
            clas = defineClass( name, raw, 0, raw.length );
        } catch( IOException ie ) {
        }
        if (clas==null) {
            clas = findSystemClass( name );
        }

        if (resolve && clas != null)
            resolveClass( clas );

        if (clas == null)
            throw new ClassNotFoundException( name );
        return clas;
    }
}

In current directory create a folder ./myclass/somepackage with the  
following two files:

package somepackage;

public class MyData {
    private String name;

    public MyData() {
        name = "No one can read me";
    }
        
    public String getName() {
        System.out.println("private method called");
        return (name);
    }
}

package somepackage;

public class MyTest implements Runnable {
        MyData m;
        
        public MyTest() {
                m = new MyData();
        }
        
        public void run() {
                System.out.println(m.getName());
        }
}

Compile both these classes, then change the MyData.getName method to  
private access, and recompile MyData.



Stephen


-------------------------------------------------------------------------
Sponsored by: Watchfire

Methodologies & Tools for Web Application Security Assessment
With the rapid rise in the number and types of security threats, web 
application security assessments should be considered a crucial phase in 
the development of any web application. What methodology should be 
followed? What tools can accelerate the assessment process? 
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9h
--------------------------------------------------------------------------