[Owasp-dotnet] Re: [SC-L] By default, the Verifier is disabled on .Net and Java
Michael Silk
michaelslists at gmail.com
Thu May 4 20:33:08 EDT 2006
> 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"
I don't think so; they've got their Crack the Verifier initiative; and
honestly, I don't think it's a big deal of verification isn't on by
default on the desktop vm; when you double-click a jar it runs in a
new vm, not with a current app you might also be running.
As long as j2ee containers (tomcat as Jeff says, websphere as I've
heard, and BEA WebLogic as someone else suggested) all run with
verification I don't think it's a big deal [but interesting to note],
is it?
FWIW I've seen this "issue" come up many many times in the java forums
and it's never taken this track. It's interesting to see it develop
this way ...
-- Michael
More information about the SC-L
mailing list