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

[dinis at ddplus.net (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 Manager Sandbox.

Here is a quote from 1997's Java Security 
<http://www.cigital.com/javasecurity/preface.html> (Gary McGraw and 
Eduard W. Feltern) book, page 75, Chapter Three 'Serious Holes in the 
Security Model"
/
"... *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 
<http://www.securingjava.com/chapter-five/chapter-five-7.html>/

/Another quote from Section 7 -- You're Not My Type 
<http://www.securingjava.com/chapter-five/chapter-five-7.html>/
/

/"...As mentioned in Chapter 2 
<http://www.securingjava.com/chapter-two/>, 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 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?

In fact, I would argue that you can't really say that you have an 
'airtight security' policy if the verifier is not enabled!" /

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net


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