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

[Charles Miller <cmiller () pastiche org>]

On 11/05/2006, at 6:47 PM, Stephen de Vries wrote:

> Stephen de Vries wrote:
> > The IllegalAccessError is generated when you try and access a private
> > method through the reflection API - and since the type checking is  
> > done
> > dynamically, it would be difficult (impossible?) to perform a type
> > confusion attack on code that isn't statically typed.  Code below
> > illustrates reflection access control in a simple app.
>
> So, I'll rephrase this as: The Tomcat error looks suspiciously like a
> reflection access control error, but it could be down to the type
> checking done through the dynamic class loading - and not necessarily
> the reflection API.

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



-------------------------------------------------------------------------
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
--------------------------------------------------------------------------