Re: [SC-L] By default, the Verifier is disabled on .Net and Java

[Charles Miller <cmiller () pastiche org>]

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

Of 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!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9h
--------------------------------------------------------------------------