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
|
_______________________________________________
Secure Coding mailing list (SC-L)
[email protected]
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
