[OWASP-LEADERS] Re: [Owasp-dotnet] RE: 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code

[stephen at corsaire.com (Stephen de Vries)]

On 27 Mar 2006, at 11:02, Jeff Williams wrote:

> > I am not a Java expert, but I think that the Java Verifier is NOT  
> > used on
> Apps that >are executed with the Security Manager disabled (which I  
> believe
> is the default >setting) or are loaded from a local disk (see "...  
> applets
> loaded via the file system >are not passed through the byte code  
> verifier"
> in http://java.sun.com/sfaq/)
>
> I believe that as of Java 1.2, all Java code except the core  
> libraries must
> go through the verifier, unless it is specifically disabled (java
> -noverify).

I had the same intuition about the verifier, but have just tested  
this and it is not the case.  It seems that the -noverify is the  
default setting! If you want to verify classes loaded from the local  
filesystem, then you need to explicitly add -verify to the cmd line.   
I tested this by compiling 2 classes where one accesses a public  
member of the other.  Then recompiled the other and changed the  
method access to private.  Tested on:
Jdk 1.4.2 Mac OS X
Jdk 1.5.0 Mac OS X
Jdk 1.5.0 Win XP

all behave the same.

[~/data/dev/applettest/src]java -cp . FullApp
Noone can access me!!
[~/data/dev/applettest/src]java -cp . -verify FullApp
Exception in thread "main" java.lang.IllegalAccessError: tried to  
access field MyData.secret from class FullApp at FullApp.main 
(FullApp.java:23)

Using the same code with an Applet loaded from the filesystem throws  
an IllegalAccessError exception as it should.


-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:    +44 1483 226014
Fax:    +44 1483 226068
Web:    http://www.corsaire.com