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
--------------------------------------------------------------------------
Received on May 11 2006
Intro
