WebApp Sec mailing list archives
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
From: Stephen de Vries <stephen () corsaire com>
Date: Thu, 11 May 2006 11:46:00 +0700
Jeff Williams wrote:
2) The verifier also seems to be enabled for classes running insideTomcat. 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 () 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 --------------------------------------------------------------------------
Current thread:
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Steve Brown (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Michael Silk (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Charles Miller (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 13)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Michael Silk (May 13)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Charles Miller (May 14)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Steve Brown (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 11)
- RE: [SC-L] By default, the Verifier is disabled on .Net and Java Jeff Williams (May 11)
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Michael Silk (May 11)
- <Possible follow-ups>
- Re: [SC-L] By default, the Verifier is disabled on .Net and Java Michael Silk (May 14)