By default, the Verifier is disabled on .Net and Java

[dinis at ddplus.net (Dinis Cruz)]

Jeff Williams wrote:
> Two important clarifications for Java (based on my experiments): 
>
> 1) The verifier IS enabled for the classes that come with the Java 
> platform, such as those in rt.jar.  So, for example, if you create a 
> class that tries to set System.security (the private variable that 
> points to the SecurityManager instance), you get a verification 
> exception. (If this was possible, it would allow a complete bypass of 
> the Java sandbox).
But with either Type Confusion attacks or with the Security Manager 
disabled, you can still completely bypass the Java Sandbox, right?
> 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
> So I don't think it's fair to say that most Java code is running 
> without verification.
If all jsp out there is verified then yes 99% is not a correct number, 
any idea what percentage it could be?
> But Denis is right. There is a real problem with verification, as 
> demonstrated in the message below.  This is a clear violation of the 
> Java VM Spec, yet my messages to the team at Sun developing the new 
> verifier have been ignored.  And it's a real issue, given the number 
> of applications that rely on libraries they didn't compile.  I don't 
> think a real explanation of how the Sun verifier actually works is too 
> much to ask, given the risk.
I agree, and Sun will probably do the same thing that Microsoft is doing 
at the moment: "Ignore the issue and hope that it goes away"

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060504/d13dc556/attachment.html