Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-15 Thread leichter_jerrold
| Kevin is correct, a type confusion attack will allow the bypass of the | security manager simply because via a type confusion attack you will be able | to change what the security manager is 'seeing' | | So in an environment where you have a solid Security Policy (enforced by a |

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-13 Thread Stephen de Vries
On 12 May 2006, at 09:10, Charles Miller wrote: It's not reflection: you're confusing IllegalAccessException and IllegalAccessError. For any non-Java nerd still listening in: there are two fundamental types of Throwable exception-conditions in Java: Exceptions and Errors[1]. Exceptions

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-13 Thread Stephen de Vries
On 12 May 2006, at 14:58, Dinis Cruz wrote: Michael Silk wrote: You can't disable the security manager even with the verifier off. But you could extend some final or private class that the security manager gives access to. This is not correct. With the verifier disabled there are multiple

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-13 Thread Michael Silk
Stephen, I think the reason you get the IllegalAccessError is because the VM thinks you are loading from a remote url. I don't think the user of a classloader per-se forces the verification of the class. (I wrote a class loader like yours that just loads a file with no package in the current

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-13 Thread Gary McGraw
Shall we ask ed felten to did out the old type confusion toolkit? gem -Original Message- From: Stephen de Vries [mailto:[EMAIL PROTECTED] Sent: Sat May 13 15:12:48 2006 To: Dinis Cruz Cc: Secure Coding Mailing List Subject:Re: [SC-L] By default, the Verifier is

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-12 Thread Dinis Cruz
Michael Silk wrote: You can't disable the security manager even with the verifier off. But you could extend some final or private class that the security manager gives access to. This is not correct. With the verifier disabled there are multiple ways you can jump out of the Security

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-12 Thread Dinis Cruz
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:

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-12 Thread Dinis Cruz
Gary McGraw wrote: The switch from applets vs applications security to trusted code vs untrusted code happened with the introduction of jdk 1.1 (way back when). Ed and I followed the sun marketing lead in 96 when it came to applets vs applications, but we cleared this up later in Securing

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-12 Thread Michael Silk
On 5/12/06, Dinis Cruz [EMAIL PROTECTED] 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

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-11 Thread Stephen de Vries
Michael Silk wrote: On 5/9/06, Dinis Cruz [EMAIL PROTECTED] wrote: snip Is there a example out there where (by default) java code is executed in an environment with : * the security manager enabled (with a strong security policy) and * the verifier disabled Yes. Your local

RE: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-11 Thread Jeff Williams
Stephen de Vries wrote: With application servers such as Tomcat, WebLogic etc, I think we have a special case in that they don't run with the verifier enabled - yet they appear to be safe from type confusion attacks. (If you check the startup scripts, there's no mention of running with

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-11 Thread Michael Silk
The verifier is enabled via the commandline. It is either on or off. the VM does other forms of verification though. http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79383 ... -- Michael On 5/11/06, Jeff Williams [EMAIL PROTECTED] wrote: Stephen de Vries wrote:

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-11 Thread David Eisner
Michael Silk wrote: The verifier is enabled via the commandline. It is either on or off. I'm not sure that's true. See: http://securecoding.org/pipermail/sc-l/2006/000262.html Summary: there are *three* comandline options: -verify, -noverify, and -verifyremote. It is -verifyremote that

RE: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-09 Thread Gary McGraw
The switch from applets vs applications security to trusted code vs untrusted code happened with the introduction of jdk 1.1 (way back when). Ed and I followed the sun marketing lead in 96 when it came to applets vs applications, but we cleared this up later in Securing Java

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-08 Thread Dinis Cruz
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

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-08 Thread Dinis Cruz
Stephen de Vries wrote: Java has implemented this a bit differently, in that the byte code verifier and the security manager are independent. So you could for example, run an application with an airtight security policy (equiv to partial trust), but it could still be vulnerable to type

RE: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-08 Thread Gary McGraw
That's essentially correct kevin. The idea was to be able to run not remote, but untrusted code. Note that modern readers will understand that local code can be untrusted. There is a good picture of this in securing java. gem -Original Message- From: Wall, Kevin [mailto:[EMAIL

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-08 Thread Michael Silk
On 5/9/06, Dinis Cruz [EMAIL PROTECTED] wrote: Stephen de Vries wrote: Java has implemented this a bit differently, in that the byte code verifier and the security manager are independent. So you could for example, run an application with an airtight security policy (equiv to partial

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-05 Thread David Eisner
Tim Hollebeek wrote: The fact that editing the .class file allows you to produce one that causes the JVM to crash is pretty strong evidence the verifier was NOT used to validate the file. Right. What follows is a summary of what we know so far, and what I think is going on. The details

Re: [Owasp-dotnet] Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-05 Thread Michael Silk
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

RE: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-05 Thread Stephen de Vries
Jim Halfpenny on the Webappsec list has discovered that BEA's JRockit JDK _does_ use verification by default, his complete post quoted below (the test was to access private methods on a class): Hi, BEA JRockit verifies by default and as far as I am aware does not offer a -noverify option. $

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-05 Thread Stephen de Vries
David Eisner wrote: snip some good research What determines when access to a private member is illegal? Is it, in fact, the bytecode verifier? Yes, it's done by the fourth pass of the verifier as described here: http://java.sun.com/sfaq/verifier.html#HEADING13 Interestingly, Sun have

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-04 Thread Dinis Cruz
Wall, Kevin wrote: Also, from the results of your test, it seems to indicate that SOME TYPE of verification is taking place, but if all you did was change a few ARBITRARY bytes in the .class file, I don't think that proves the byte code verifier is being being run in it's entirety. I agree

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-04 Thread Michael Silk
On 5/4/06, Dinis Cruz [EMAIL PROTECTED] wrote: Wall, Kevin wrote: Also, from the results of your test, it seems to indicate that SOME TYPE of verification is taking place, but if all you did was change a few ARBITRARY bytes in the .class file, I don't think that proves the byte code

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-04 Thread David Eisner
Dinis Cruz wrote: Ok, I just did some further tests and I think I can say that Java (version 1.5.0_06) has similar verification issues to the ones I discovered on the .Net Framework (see links in my previous post). [...] This should prove that the verifier is not enabled by default on java

RE: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-04 Thread Tim Hollebeek
$ java -cp . -noverify HelloWorld # # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d7415fb, pid=3512, tid=2260 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode) # Problematic frame: # V

RE: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-04 Thread Gary McGraw
I'm psyched about this thread. Rock on guys. For those of you who may need some basics, you might want to read Securing Java (a book I wrote with Ed Felten in 1999...the first edition in 1996 was called Java Security). The book is available completely for free in searchable format at

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-04 Thread Dinis Cruz
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

RE: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-03 Thread Jeff Williams
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

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-03 Thread David Eisner
Wall, Kevin wrote: same intuition about the verifier, but have just tested this and it is not the case. It seems that the -noverify is the default setting! If you want to verify classes loaded from the local filesystem, then you need to explicitly add -verify to the cmd line.

RE: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-03 Thread Wall, Kevin
David Eisner wrote... Wall, Kevin wrote: The correct attribution for bring this up (and the one whom you are quoting) is Dinis Cruz. same intuition about the verifier, but have just tested this and it is not the case. It seems that the -noverify is the default setting! If you want to

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-03 Thread Dinis Cruz
Ok, I just did some further tests and I think I can say that Java (version 1.5.0_06) has similar verification issues to the ones I discovered on the .Net Framework (see links in my previous post). Here is a full description of my test (which is a variation of the one done by Stephen de Vries

Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-03 Thread Michael Silk
Verifier in 1.5 is definately OFF by default: to confirm this do the following: 1. Create this class: == public class Foo { public static int k = 23; static { System.out.println(initially k: + k); } public static void m(){ System.out.println(m()