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