On 5/9/06, Dinis Cruz <[EMAIL PROTECTED]> 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
_______________________________________________
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
