Jeff Williams wrote:
>>> 2) The verifier also seems to be enabled for classes running inside
> Tomcat. I'm >> not sure about other J2EE containers.
>> This is interesting, do you have any documentation to back this up?
> Ideally there > would be a document somewhere which listed which J2EE
> containers run with the > verifier on by default
>
> I determined this experimentally since I cannot find any authoritative
> documentation showing exactly when classes are verified and when they are
> not. The test is essentially the same as the other tests discussed in this
> thread.
>
> You can try it yourself with the attached zip file. Start with TestServlet
> calling public method named privateMethod() in Foo.java. Compile both files
> "javac -classpath servlet-api.jar *.java". Then edit Foo.java to make
> privateMethod really private. Then recompile just Foo.java "javac
> -classpath servlet-api.jar Foo.java". Copy the class files into the
> WEB-INF\classes folder. Then drop the whole TestServlet folder into the
> webapps directory in a standard Tomcat directory. Run Tomcat's startup.bat
> and browse to http://localhost:8080/TestServlet/test.
>
> Here's the output. I'd love to hear what happens with this in other
> servers, if anyone has WebSphere or WebLogic lying around.
>
> java.lang.IllegalAccessError: tried to access method Foo.privateMethod()V
> from c
> lass TestServlet
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).
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.
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.
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;
Object obj = myClass.newInstance();
Method m = myClass.getDeclaredMethod("getName", new Class[] {});
System.out.println(m.invoke(obj, new Object[] {}).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:
java.lang.IllegalAccessException: Class classloader.Main can not access
a member of class somepackage.MyData with modifiers "private"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.reflect.Method.invoke(Method.java:578)
at classloader.Main.main(Main.java:41)
--
Stephen de Vries
Corsaire Ltd
E-mail: stephen_at_corsaire.com
Tel: +44 1483 226014
Fax: +44 1483 226068
Web: http://www.corsaire.com
-------------------------------------------------------------------------
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
