Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [SC-L] By default, the Verifier is disabled on .Net and Java |
|---|---|
| Date: | Mon, 15 May 2006 12:51:06 +1000 |
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.
Please read the java documentation.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#40222
Maybe you are also interested in BCEL by apache.
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.
What do you mean by verification?
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?
"We" ? Why don't _YOU_ do it. This is your crusade.
Your code must break out of a "-noverify" sandbox, but fail to break a -verifiy sandbox.
Dinis Cruz Owasp .Net Project www.owasp.net
-- Michael
------------------------------------------------------------------------- Sponsored by: Watchfire
https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9h --------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [SC-L] By default, the Verifier is disabled on .Net and Java, Charles Miller |
|---|---|
| Next by Date: | RE: Re; Comparison report on web app security scanners, Holger.Peine |
| Previous by Thread: | Re: [SC-L] By default, the Verifier is disabled on .Net and Java, Michael Silk |
| Next by Thread: | Re: [SC-L] By default, the Verifier is disabled on .Net and Java, leichter_jerrold |
| Indexes: | [Date] [Thread] [Top] [All Lists] |