[SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-15 Thread j lunerwood
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).
skipped...


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=ind0107L=java-securityP=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


Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-15 Thread leichter_jerrold
| 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


[SC-L] New podcast (sneak preview)

2006-05-15 Thread Gary McGraw
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 SP 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