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@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
