Stephen de Vries wrote:
Java has implemented this a bit differently, in that the byte code
verifier and the security manager are independent. So you could for
example, run an application with an airtight security policy (equiv to
partial trust), but it could still be vulnerable to type confusion
attacks if the verifier was not explicitly enabled. To have both
enabled you'd need to run with:
java -verify -Djava.security.policy ...
This is a very weird decision by the Java Architects, since what is the
point of creating and enforcing a airtight security policy if you can
jump strait out of it via a Type Confusion attack?
In fact, I would argue that you can't really say that you have an
'airtight security' policy if the verifier is not enabled!
Right?
Is there a example out there where (by default) java code is executed in
an environment with :
* the security manager enabled (with a strong security policy) and
* the verifier disabled
Dinis Cruz
Owasp .Net Project
www.owasp.net
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
