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

[gem at cigital.com (Gary McGraw)]

Shall we ask ed felten to did out the old type confusion toolkit?

gem

 -----Original Message-----
From:   Stephen de Vries [mailto:stephen at corsaire.com]
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 disabled on .Net and Java


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  
> ways you can jump out of the Security Manager Sandbox.
>
> Here is a quote from 1997's Java Security (Gary McGraw and Eduard  
> W. Feltern) book, page 75, Chapter Three 'Serious Holes in the  
> Security Model"

I'm a bit sceptical of this, I know Sun's track record on fixing JVM  
vulnerabilities hasn't always been great, but 9 years seems a bit  
excessive!  Unfortunately the book doesn't provide any more details  
on the vulnerabilities so we're left guessing whether these still  
affect modern JVMs.  Even with verification turned off with the - 
noverify option, I think it would be difficult to break out of a  
defined security manager.

> "... The Type Confusion Tool Kit The Princeton team, as a  
> feasibility demonstration, created a tool kit that allows any type  
> confusion attack to be turned into a disarming of Java's security.  
> In other words, the tool kit servers as a way of turning a small  
> security breach into a complete system penetration. The type  
> confusion tool kit has not been released to the public, and is  
> considered to dangerous to describe in any detail here..."
>
> A variation of this quote can also at the bottom of this page:  
> Section 7 -- You're Not My Type
>
> Another quote from Section 7 -- You're Not My Type
> "...As mentioned in Chapter 2, every aspect of Java security  
> depends critically on the type-safety of the language. This means  
> that if Java is going to be secure, it has to make sure that all  
> pointers are properly tagged; that is, the tag must match the  
> actual type of object that is being pointed to.
>
> In a type-confusion attack, a malicious applet creates two pointers  
> to the same object-with incompatible type tags. When this happens,  
> the Java system is in trouble. The applet can write into that  
> memory address through one pointer, and read it through another  
> pointer. The result is that the applet can bypass the typing rules  
> of Java, completely undermining its security...."
>
> The example that we have been playing around here (the direct  
> access to a private member) is probably not the best one to use to  
> test the verifier, since there are multiple ways that this type of  
> illegal access can be 'accidentally' detected by the VM (in Java  
> there are some cases where the class loading process detects this,  
> and in .Net the JIT will catch it)
>
> I think that it will be better to use the examples shown in the  
> brilliant LSD paper http://lsd-pl.net/papers.html#java

The paper mentions avenues of attack through vulnerabilities in  
Netscape 4.x's JVM and IE (Mirosoft's JVM).  These are  
vulnerabilities in specific implementations of the JVM rather than  
inherent flaws in the JVM spec.  Any type confusion attacks that are  
possible because of the lack of default verification (via -verify) in  
the JRE would affect the security of the users' own local code so  
it's unlikely that this will prove to be a practical attack vector,  
IMHO.

> or a variation of the ones I discovered in .Net:
>
> Possible Type Confusion issue in .Net 1.1 (only works in FullTrust)  
> (http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx)
> Another Full Trust CLR Verification issue: Exploiting Passing  
> Reference Types by Reference (http://owasp.net/blogs/dinis_cruz/ 
> archive/2005/12/28/393.aspx)
> Another Full Trust CLR Verification issue: Changing Private Field  
> using Proxy Struct (http://owasp.net/blogs/dinis_cruz/archive/ 
> 2005/12/28/394.aspx)
> Another Full Trust CLR Verification issue: changing the Method  
> Parameters order (http://owasp.net/blogs/dinis_cruz/archive/ 
> 2005/12/26/390.aspx)
> In fact, it would be great to have a 'verifier checker' tool. A set  
> of scripts that would test for verifier issues on Java execution  
> environments (this would make it very easy to detect who is using  
> the verifier and what type of verification is performed).
>
> After this explanation, Stephen, do you still disagree with my  
> original comments:
>
> "This is a very weird decision by the Java Architects, since what  
> is the point of creating and enforcing a airtight security policy  
> if you can jump strait out of it via a Type Confusion attack?

This is speculation.  We don't know if it's possible to break the  
security manager through a type confusion attack - the one reference  
we have is 9 years old and doesn't say much, the other targets  
specific implementation flaws older JVMs.  Java verification and  
security has many layers (as we've seen in trying to pinpoint exactly  
when it happens!), so I don't think it's accurate to equate a lack of  
local code verification with a complete breakdown of the security  
manager - unless someone demonstrates otherwise.

regards,
Stephen


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------