Secure Coding mailing list archives
By default, the Verifier is disabled on .Net and Java
From: gem at cigital.com (Gary McGraw)
Date: Mon, 8 May 2006 19:22:50 -0400
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. ----------------------------------------------------------------------------
Current thread:
- By default, the Verifier is disabled on .Net and Java, (continued)
- By default, the Verifier is disabled on .Net and Java Dinis Cruz (May 03)
- By default, the Verifier is disabled on .Net and Java David Eisner (May 04)
- By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 04)
- By default, the Verifier is disabled on .Net and Java Dinis Cruz (May 03)
- By default, the Verifier is disabled on .Net and Java Dinis Cruz (May 03)
- By default, the Verifier is disabled on .Net and Java Michael Silk (May 04)
- By default, the Verifier is disabled on .Net and Java Gary McGraw (May 04)
- By default, the Verifier is disabled on .Net and Java David Eisner (May 04)
- By default, the Verifier is disabled on .Net and Java Stephen de Vries (May 04)
- By default, the Verifier is disabled on .Net and Java Gary McGraw (May 05)
- By default, the Verifier is disabled on .Net and Java Wall, Kevin (May 08)
- By default, the Verifier is disabled on .Net and Java Gary McGraw (May 08)
- By default, the Verifier is disabled on .Net and Java Gary McGraw (May 09)
- By default, the Verifier is disabled on .Net and Java Dinis Cruz (May 12)
- By default, the Verifier is disabled on .Net and Java Jeff Williams (May 11)
- By default, the Verifier is disabled on .Net and Java Michael Silk (May 11)
- By default, the Verifier is disabled on .Net and Java David Eisner (May 11)
- By default, the Verifier is disabled on .Net and Java Michael Silk (May 11)
- By default, the Verifier is disabled on .Net and Java Gary McGraw (May 13)
- Message not available
- By default, the Verifier is disabled on .Net and Java Dinis Cruz (May 14)
- By default, the Verifier is disabled on .Net and Java Michael Silk (May 14)
- Message not available