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:[EMAIL PROTECTED]
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.
[EMAIL PROTECTED] 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@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.
___
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
