App server ClassLoaders are a law unto themselves. If you try to use an
object whose class was loaded from a WAR file, in an EJB for example,
you will get a ClassCastException, even though the class is loaded and
available, because a different ClassLoader loaded it.

This is a whole area of expertise and black magic that takes even
respectable Java programmers a fair while to get their head around :) I
believe that Stephen de Vries is largely right, because the App Server
defines it's own ClassLoaders, it must be using the reflection APIs to
do this and that's why you see them behaving differently, however the
classes loaded from the javax.* packages (thus, HttpServletRequest,
ServletResponse etc) will (probably) be loaded through the
standard/System ClassLoader when the App server starts up as opposed to
when the specific application is deployed. Thus they have 'static
knowledge' of the javax API classes, but do not have 'static knowledge'
of the classes you've deployed in your WAR/EAR as these are all loaded
by the vendor specific ClassLoader.

gives a
good article about it, but suffice to say that App server class loading
is different to Desktop java classloading which generally uses only one
ClassLoader and has a much laxer policy on what it will allow, which is
different again to Applet ClassLoading

I'm still not sure how you would exploit any of this for malicious
purposes anyway, in order to call a private method in someone elses code
you'd have to subvert the .class file containing that private method
anyway, in which case simply calling the private method would be the
least damage you could do. This, I believe, is why Applets require
signing before a browser will allow them to do things like opening
network sockets (except back to the host they were loaded from) and
writing to local file systems - so that the .class files can't be
subverted in this way.

Cheers,
Steve.

Stephen de Vries wrote:
Stephen de Vries wrote:

>With application servers such as Tomcat, WebLogic etc, I think we have a
>special case in that they don't run with the verifier enabled - yet they
>appear to be safe from type confusion attacks. (If you check the
>startup scripts, there's no mention of running with -verify).
>
>
K.


>The difference between the app servers and a regular compiled Java app
>is that the servers load code dynamically and use reflection to access
>fields and methods, so the app servers have no static knowledge of the
>types defined in user code.
>
>
Apologies for the above incorrect statement. App servers _do_ have
knowledge of the static type since they define the base classes in the
servlet and other API's.


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


>package classloader;
>>
>import java.lang.reflect.Method;
>import somepackage.MyData;
>>
>public class Main {
>>
>public Main() {
>}
>>
>public static void main(String[] args) {
>try {
>>
>Class myClass = MyData.class;
>obj = myClass.newInstance();
>Method m = myClass.getDeclaredMethod("getName", new Class[] {});
>System.out.println(m.invoke(obj, new [] {}).toString());
>} catch (Exception e) {
>e.printStackTrace();
>}
>}
>>
>}
>>
>package somepackage;
>>
>public class MyData {
>private String name;
>>
>public MyData() {
>name = "No one can read me";
>}
>>
>private String getName() {
>return name;
>}
>}
>>
>Executing the app produces:
>>
>Class classloader.Main can not access
>a member of class somepackage.MyData with modifiers "private"
>at (Reflection.java:65)
>at (Method.java:578)
>at classloader.Main.main(Main.java:41)
>>
>>
>>
>
>
>

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!

5/11/06, Steve Brown <steve (AT) kabarty (DOT) comwrote:
App server ClassLoaders are a law unto themselves. If you try to use an
object whose class was loaded from a WAR file, in an EJB for example,
you will get a ClassCastException, even though the class is loaded and
available, because a different ClassLoader loaded it.

This is a whole area of expertise and black magic that takes even
respectable Java programmers a fair while to get their head around :) I
believe that Stephen de Vries is largely right, because the App Server
defines it's own ClassLoaders, it must be using the reflection APIs to
do this and that's why you see them behaving differently, however the
classes loaded from the javax.* packages (thus, HttpServletRequest,
ServletResponse etc) will (probably) be loaded through the
standard/System ClassLoader when the App server starts up as opposed to
when the specific application is deployed. Thus they have 'static
knowledge' of the javax API classes, but do not have 'static knowledge'
of the classes you've deployed in your WAR/EAR as these are all loaded
by the vendor specific ClassLoader.

gives a
good article about it, but suffice to say that App server class loading
is different to Desktop java classloading which generally uses only one
ClassLoader and has a much laxer policy on what it will allow, which is
different again to Applet ClassLoading

I'm still not sure how you would exploit any of this for malicious
purposes anyway, in order to call a private method in someone elses code
you'd have to subvert the .class file containing that private method
anyway, in which case simply calling the private method would be the
least damage you could do. This, I believe, is why Applets require
signing before a browser will allow them to do things like opening
network sockets (except back to the host they were loaded from) and
writing to local file systems - so that the .class files can't be
subverted in this way.

you don't need to subvert class files.

you need to review the posted examples. the point is that if you
convice _your_ class, that the method you are calling is public, not
private, then it's all good at runtime providing the verifier is off.
-- Michael

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!

The "verifier" is enabled via the commandline. It is either on or off.

the VM does other forms of "verification" though.

#79383

-- Michael

5/11/06, Jeff Williams <jeff.williams (AT) aspectsecurity (DOT) comwrote:
Stephen de Vries wrote:
With application servers such as Tomcat, WebLogic etc, I think we have a
special case in that they don't run with the verifier enabled - yet they
appear to be safe from type confusion attacks. (If you check the
startup scripts, there's no mention of running with -verify).

You're right -- I checked that too. So I think it's just too simple to talk
about the verifier being either on or off. It appears to me that the
verifier can be enabled for some code and not for other code. I think
you're right that this behavior has something to do with the classloader
that is used, but I'd really like to understand exactly what the rules are.

--

Secure Coding mailing list (SC-L)
SC-L (AT) securecoding (DOT) org
List information, subscriptions, etc -
List charter available at -

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!

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:

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:

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!

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:

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:
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: /
somepackage/MyTest.class
Loading class: /
Runnable.class
Loading class: /

Loading class: /
somepackage/MyData.class
Loading class: /
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.IException;

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

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

private byte[] getBytes( String filename ) throws IException {
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 IException( "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( IException 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!

Stephen,

I think the reason you get the IllegalAccessError is because the VM
thinks you are loading from a remote url.

I don't think the user of a classloader per-se forces the
verification of the class. (I wrote a class loader like yours that
just loads a file with no package in the current dir and was able to
access the private method).

You can also note that your class isn't verified if -noverify is
passed (perhaps this is obvious :)
-- Michael

5/13/06, Stephen de Vries <stephen (AT) corsaire (DOT) comwrote:

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:

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:
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: /
somepackage/MyTest.class
Loading class: /
Runnable.class
Loading class: /

Loading class: /
somepackage/MyData.class
Loading class: /
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.IException;

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

public CustomLoader(String path) {
this.path = path;
}
--
private byte[] getBytes( String filename ) throws IException {
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 IException( "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( IException 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

Secure Coding mailing list (SC-L)
SC-L (AT) securecoding (DOT) org
List information, subscriptions, etc -
List charter available at -

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!

13/05/2006, at 3:30 PM, Stephen de Vries wrote:
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?

This is possible. I can't find anywhere in the VM spec that says
under what circumstances the verifier is invoked, but it _does_ say
that the purpose of the verifier is to vet untrusted code.

If you load classes directly by adding them to the system classpath,
Java assumes you trust them and doesn't bring up any kind of sandbox
beyond its built-in type and bounds checking mechanisms. It seems
logical that Java would skip the expensive bytecode verification step
on classes loaded by the system classloader, and then invoke it for
custom classloaders that might be loading classes from untrusted
sources.

course, 'sounds logical' often has only a vague relationship with
what Java actually does, so I wouldn't count on this being the case
without more concrete evidence. :)

C

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!