By default, the Verifier is disabled on .Net and Java

[michaelslists at gmail.com (Michael Silk)]

On 5/9/06, Dinis Cruz <dinis at ddplus.net> wrote:
> Jeff Williams wrote:
> > But Dinis 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.
> And 9 days into this discussion, Sun's comment (or somebody from Sun) is
> still nowhere to be seen (Microsoft is not the online one MIA :).
>
> Anybody had any luck with their off list attempts to get a comment on
> this issue? What about the main Java Application Server developers?
> WebSphere , WebLogic, JBoss, Enhydra, Blazix, Resin, JOnAS etc...
>
> It is important that they participate in this discussion, because
> amongst other things I would like them to answer my next questions,
> which are:
>
> "What is the point of the verifier?' , 'Why use it? and 'What are the
> real security advantages of enabling the verifier if the code is
> executed in an environment with the security manager disabled?'

Huh? You can find what it does here:

http://java.sun.com/sfaq/verifier.html

The security manager and the verifier are different.

The security manager allows you to restrict runtime-knowledge type
things. Connecting a socket, opening a file, exiting the vm, and so
on.

The verifier deals with other things. As you know, right?


> So far we have identified several cases where:
>
> * the Java verifier is NOT enabled by default
>
> - Local code (i.e. loaded from the local system)
>
> * the Java verifier is enabled by default
>
> - classes that come with the Java platform
> - classes running inside Tomcat
> - classes running inside BEA WebLogic
>
> Given that the main attack vector (to exploit the lack of verification)
> is the same for all cases mentioned above (the attack vector being the
> injection of malicious Java code on the application being executed) then
> I would like to know the reason for the inconsistency?
>
> I also would like to ask if the following comments are correct:
>
> Option A) 99% of the Java code deployed to live systems is executed in
> an environment with the verifier disabled
>
> Option B) 99% of the Java code deployed to live systems is executed in
> an environment with the verifier disabled OR with the security manager
> disabled

I'd say no. We already know BEA/Tomcat/(And from my knowledge
Websphere) all run with verification ON by default. All these 3 don't
take up only "1%" of all java code.


> If not, what value should Option A and B be? 10%, 50%, 75?

Download the app servers and check the documentation? I'd guess most
have it on by default. Not off. Just my guess though ...

-- Michael