Johan,
Yes, the attacks are feasible. Please refer to the Java language
spec. on inner/outer class semantics and fool around with simple test
cases (and javap -c) to show yourself what's happening during the
compile step.
Attacks require getting code inside the victim VM but mine pass
verification silently (even with verifier turned on). Calling the
privileged class to lure it into doing your bidding requires only an
open package (not signed and sealed -- again see spec.) and other fun-
and-excitement can be had if the Developer hasn't been careful enough
to define the PriviledgedAction subclass as an explicit top-level
class and they've passed information to-and-fro using the inner class
syntactic sugar--rather than explicit method calls defined pre-
compile time.
----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F
http://www.cigital.com
Software Confidence. Achieved.
On May 21, 2006, at 8:23 AM, Johan Peeters wrote:
That sounds like a very exciting idea, but I am not sure about the
mechanics of getting that to work. I assume the permissions for the
untrusted code would be in the closure's environment. Who would put
them there? How would the untrusted code call privileged code?
Has anyone done this?
kr,
Yo
Gary McGraw wrote:
Hi yo!
Closure is very helpful when doing things like crossing trust
boundaries. If you look at the craziness involved in properly
invoking the doprivilege() stuff in java2, the need for closure is
strikingly obvious.
However, closure itself is not as important as type safety is.
So the fact that javascript may (or may not) have closure fails in
comparison to the fact that it is not type safe.
Ajax is a disaster from a security perspective.
gem
-----Original Message-----
From: Johan Peeters [mailto:[EMAIL PROTECTED]
Sent: Sat May 20 15:44:46 2006
To: Gary McGraw
Cc: Mailing List, Secure Coding; SSG
Subject: Re: [SC-L] Ajax one panel
I think Java would have been a better language with closures, but
I am intrigued that you raise them here. Do you think closures
present security benefits? Or is this a veiled reference to Ajax?
I guess JavaScript has closures.
kr,
Yo
Gary McGraw wrote:
Ok...it was java one. But it seemed like ajax one on the show
floor. I participated in a panel yesterday with superstar bill
joy. I had a chance to talk to bill for a while after the gig
and asked him why java did not have closure. Bill said he was on
a committee of five, and got out-voted 2 to 3 on that one (and
some other stuff too). You know the other pro vote had to be guy
steele. Most interesting. Tyranny of the majority even in java.
Btw, bill also said they tried twice to build an OS on java and
failed both times. We both agree that a type safe OS will happen
one day.
Here's a blog entry from john waters that describes the panel
from his point of view.
http://www.adtmag.com/blogs/blog.aspx?a=18564
gem
www.cigital.com
www.swsec.com
Sent from my treo.
--------------------------------------------------------------------
--------
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
--
Johan Peeters
program director
http://www.secappdev.org
+32 16 649000
----------------------------------------------------------------------------
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
