Secure Coding mailing list archives
By default, the Verifier is disabled on .Net and Java
From: gem at cigital.com (Gary McGraw)
Date: Sat, 13 May 2006 16:42:11 -0400
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. ----------------------------------------------------------------------------
Current thread:
- By default, the Verifier is disabled on .Net and Java, (continued)
- By default, the Verifier is disabled on .Net and Java David Eisner (May 04)
- By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 04)
- By default, the Verifier is disabled on .Net and Java Gary McGraw (May 05)
- By default, the Verifier is disabled on .Net and Java Wall, Kevin (May 08)
- By default, the Verifier is disabled on .Net and Java Gary McGraw (May 08)
- By default, the Verifier is disabled on .Net and Java Gary McGraw (May 09)
- By default, the Verifier is disabled on .Net and Java Dinis Cruz (May 12)
- By default, the Verifier is disabled on .Net and Java Jeff Williams (May 11)
- By default, the Verifier is disabled on .Net and Java Michael Silk (May 11)
- By default, the Verifier is disabled on .Net and Java David Eisner (May 11)
- By default, the Verifier is disabled on .Net and Java Michael Silk (May 11)
- By default, the Verifier is disabled on .Net and Java Gary McGraw (May 13)
- Message not available
- By default, the Verifier is disabled on .Net and Java Dinis Cruz (May 14)
- By default, the Verifier is disabled on .Net and Java Michael Silk (May 14)
- Message not available
- By default, the Verifier is disabled on .Net and Java j lunerwood (May 14)
- By default, the Verifier is disabled on .Net and Java leichter_jerrold at emc.com (May 15)