[SC-L] New podcast (sneak preview)
Hi all, Tomorrow, we'll announce the existence of the Silver Bullet Security Podcast with Gary McGraw. Woo hoo. The first interview is with Avi Rubin. This activity is sponsored by IEEE S&P Magazine...who by now all sc-l readers should know well! See www.cigital.com/silverbullet Hope you all like it! gem 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. ___ 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
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
| 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' | | 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) | | 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 This is taking a bit too extreme a point of view. The issue here is what's trusted, and for what purpose. *Something* has to be trusted. The verifier, the security manager, the JVM - if you can't trust these, you have no hope. The Java/.Net defaults explicitly say: (a) I trust the compiler not to generate dangerous code; (b) I trust the local user not to put stuff on the local disk where it can be executed unless it came from the compiler and he trusts it; (c) I trust the OS to protect the stuff on the local disk. On the other hand, I *don't* trust stuff that comes off the network. Given the realities of the last 10 years of virus-like attacks, this trust model may well be questionable. But keep in mind that just because a Java application passes every verification and is acceptable to even a very strict security policy doesn't mean it isn't a trojan horse at a higher semantic level! Verifying bytecodes certainly blocks many attack vectors, and is a fine idea - but things are not all black and white. Runtime checking will inherently cost you performance. Someone will always have an application where the extra cost is "too high" relative to the risk of running unverified. Rather than absolute statements about requiring verification for all user-written code - while leaving it off for the large volume of system-provided code - we need a more nuanced view, a better way to quantify risks and costs and trade them off. Otherwise, the same forces that to this day argue that Java is unacceptable because of the overhead of garbage collection will continue to push for writing in completely unsafe languages. -- Jerry ___ 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
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
On 5/14/06, Dinis Cruz <[EMAIL PROTECTED]> wrote:
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
___
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
[SC-L] By default, the Verifier is disabled on .Net and Java
in reply to >Dinis Cruz dinis at ddplus.net >Sun May 14 03:40:20 EDT 2006 <...skipped...> >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).I guess this is exactly the logic that was behind the implementation decision that by default Code isn't verified when and only when it is granted "All Permissions" mentioned here http://archives.java.sun.com/cgi-bin/wa?A2=ind0107&L=java-security&P=1305 Though the post at the link avove talks only about boot strap classes, i guess this policy is now implemented across the whole JVM (obviously some digging through the java sources would be needed to confirm this) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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
