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

[dinis at ddplus.net (Dinis Cruz)]

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'

In both .Net and Java, the sandboxes logic (CAS and Security manager) 
are external to the the JVM/CLR, that is the security checks ("can I 
access this file?", "do I have permissions to call this method?", 
etc...) are performed in the middle of the core Framework libraries. 
Basically what the core Framework developers do, is to analyze all 
public entry points, and make sure that all are protected with a 
Security Demand (using .Net terminology).

These public methods will then call private methods, who will be the 
ones that actually access the resources being protected (note that in 
these private methods there are no security checks).

So in an environment where you have a solid Security Policy (enforced by 
a Security Manager) but the verifier is NOT enabled, then to jump out of 
the sandbox all that you need to do is to create a Type Confusion 
exploit that allows you to access a private member that either: calls 
the protected resource directly or disables the Security Manager (which 
based on the description provided is the demo that I think Ed Felten did).

Of course that there will be other ways to exploit a non-verify world. 
Without verification it should be possible to create Buffer Overflows 
and other types of direct manipulation of memory objects which all occur 
before the security manager has a change to do anything.

Using a 'Matrix' Analogy, the Security Manager is the Police Department 
that operates inside the virtual world, where the verifier is the one 
that make sure that all characters (including the Police) behaves 
accordingly to the rules defined for that virtual world. In this analogy 
Neo (the hero) was able to perform several Type Safety or Verifier 
attacks which gave him those extra powers :)

I will stick to my guns and say that in a Virtual Machine environment 
like the JVM or CLR it doesn't make sense to have the overhead of a 
security system (like CAS or Security Manager) if the verifier is disabled.

Basically code executed with no verification is as 'secure' and 
contained as unmanaged code.

And remember that this code will be able to access ALL resources that 
the account used to execute that code has (from emails to VPNs to 
documents to online financial services, etc...)

But probably the best way forward (since the guys from SUN and other 
Java Application server can't be bothered (or don't have permission) to 
participate in this discussion) will be to do a proof of concept example.

Why don't we do a 'break from a non verified Sandbox' challenge?

Dinis Cruz
Owasp .Net Project
www.owasp.net

Wall, Kevin wrote:
> Gary McGraw wrote...
>
>   
> > Shall we ask ed felten to did out the old type confusion toolkit?
> >     
>
> That might be a good idea, but depending on the exact exploits
> the 2 of you used, they may not work on JDK 1.5. However--and this
> is just a guess--that in principle, type confusion attacks could
> allow you to by-pass at least some of the SecurityManager
> permission checks, and so I agree that you really ought to have
> the verifier enabled if you are going to use the security manager.
>
> ---
> Kevin W. Wall         Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com       Phone: 614.215.4788
> "The reason you have people breaking into your software all 
> over the place is because your software sucks..."
>  -- Former whitehouse cybersecurity advisor, Richard Clarke,
>     at eWeek Security Summit
>
>
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org on behalf of Gary McGraw
> Sent: Sat 5/13/2006 4:42 PM
> To: Stephen de Vries; Dinis Cruz
> Cc: Secure Coding Mailing List
> Subject: Re: [SC-L] By default, the Verifier is disabled on .Net and Java
>  
> Shall we ask ed felten to dig 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.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> 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 communication is the property of Qwest and may contain confidential or
> privileged information. Unauthorized use of this communication is strictly 
> prohibited and may be unlawful.  If you have received this communication 
> in error, please immediately notify the sender by reply e-mail and destroy 
> all copies of the communication and any attachments.
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060514/de28fdec/attachment.html