Michael Silk wrote:
You can't disable the security manager even with the verifier off. ButThis 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" "... 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 or a variation of the ones I discovered in .Net:
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 |
_______________________________________________ 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
