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

[michaelslists at gmail.com (Michael Silk)]

On 5/12/06, Dinis Cruz <dinis at ddplus.net> wrote:
>  Michael Silk wrote:
>
>
> "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.
>
>  Of course they are, but it is pointless to have only ONE of them enabled.

No it isn't.


> You need BOTH Security Manager and Verifier to start to have a Sandbox (and
> even then the Sandbox's security will depend on the security policies)

You can have a sandbox without the verifier.


> The security manager allows you to restrict runtime-knowledge type
>  things. Connecting a socket, opening a file, exiting the vm, and so
>  on.
>
>  Sure, but when you have a security policy that restricts access to sockets
> files, if the code you are trying to restrict is executed with -noverify,
> then there are ways around those restrictions and have 'unauthorized' access
> to those sockets or files.

How?


> 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.
>
>  Ok, but what about the security manager?
>
>  I agree that in Option A) the value is not 99% (since the
> BEA/Tomcat/Webshepre code will take more that %1)
>
>  But on Option B) (" Java code deployed to live systems is executed in an
> environment with the verifier disabled OR with the security manager
> disabled" ), which it the one that matters, we are still at 99% since the
> only code that falls outside that category (i.e. executed with the verifier
> AND the security manager enabled) is the mobile code which is executed under
> the default browser Java policies (we have to exclude the mobile Java code
> which requests and is granted more privileges).

Are you talking about java desktop applications now instead of j2ee
websites? If so, then who cares? You'll be running inside a new vm.


> 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 ...
>
>  Am I the only one that finds it surprising that such a pillar of Java
> Security is not properly known and information about 'who does what' doesn't
> seem to be readily available?

What are you talking about? Documentation _is_ readily available and
has been provided throughout this entire discussion.


>  Dinis Cruz
>  Owasp .Net Project
>  www.owasp.net

-- Michael