By default, the Verifier is disabled on .Net and Java

[gem at cigital.com (Gary McGraw)]

That's essentially correct kevin.  The idea was to be able to run not remote, but untrusted code.  Note that modern 
readers will understand that local code can be untrusted.  There is a good picture of this in securing java.

gem

 -----Original Message-----
From:   Wall, Kevin [mailto:Kevin.Wall at qwest.com]
Sent:   Mon May 08 19:17:22 2006
To:     Dinis Cruz; Stephen de Vries
Cc:     Secure Coding Mailing List
Subject:        RE: [SC-L] By default, the Verifier is disabled on .Net and Java

Dinis Cruz writes...

> Stephen de Vries wrote:
> > Java has implemented this a bit differently, in that the byte code 
> > verifier and the security manager are independent.  So you could for

> > example, run an application with an airtight security policy (equiv
to 
> > partial trust), but it could still be vulnerable to type confusion 
> > attacks if the verifier was not explicitly enabled.  To have both 
> > enabled you'd need to run with:
> > java -verify -Djava.security.policy ...
> 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!
>
> Right?
>
> Is there a example out there where (by default) java code is 
> executed in an environment with :
>
>     * the security manager enabled (with a strong security policy) and
>     * the verifier disabled

Just a hunch, but I suspect that it was designed this way to support
mobile code, or more specifically applets. There is a security manager
enabled (policy not airtight though; see McGraw/Felten's book on the
subject)
with applets, and the byte code verifier only verifies *remotely* loaded
classes,
which are the only ones presumed to be hostile. Dumb assumption, I know,
but
initially applets ran so slow, Sun probably had little choice if they
hoped
to "sell" applets. Besides, back then most of the hostile code WAS
coming
from different attack vectors--infected floppies or ftp'ing / running
infected code. AV software monitored that attack vector, but not
executable
code coming in via HTTP through your browser. (Many do today, though.)
But the assumption Sun made back then was that all locally loaded
classes
could be trusted and therefore were type-safe.

In retrospect, several wrong decisions were made regarding web security.
(Don't
even get me started on Radio-ActiveX! ;-) But as they say, backward
compatibility
is the curse of software design, so we probably are stuck with it.

Fortunately the verifier is pretty simple to enable in Java. OTOH,
coming
up with a good security policy is not so easy. I've only done it twice
and
it's been a laborious process each time assuming you start with
essentially
a fail-safe "no permissions" approach and only add permissions
as-needed.

Anyway, I'd say that applets were probably what drove this security
model. Curious
that applets probably now comprise less than %1 of all Java code today.

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com Phone: 614.215.4788
<... add your favorite pithy quote about hindsight here ...>


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
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.
----------------------------------------------------------------------------