Re: [SC-L] Ajax one panel
Gary McGraw wrote: 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. Did he ever articulate what happened to these OS's? I recall a presentation at OSDI 1996 by a Sun executive talking about JavaOS and the spiffy new thin clients that Sun was going to introduce. He talked about implementing the TCP/IP stack in pure Java, even with the problems of type safety in marshalling raw data. I had the impression that JavaOS failed for marketing reasons, not technical. But that impression was formed from hearing the OSDI presentation that described implementing JavaOS in the past tense. So what was the real reason? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.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] 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 ___ 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] Ajax one panel
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
Re: [SC-L] Ajax one panel
You guys are both right, but talking about different things. You can kludge pretend closure for a security critical section using the static final nonsense to make a hole on the unbound environment. I described this in some detail in a 1999 javaworld article. Havung closure would lead to a better sandbox. The luring attacks that john describes were not what I was getting at, but they lend more weight to the argument for closure. Yay, language arcana! gem -Original Message- From: Johan Peeters [mailto:[EMAIL PROTECTED] Sent: Sun May 21 09:08:14 2006 To: John Steven Cc: Gary McGraw; Mailing List, Secure Coding; SSG Subject:Re: [SC-L] Ajax one panel We may be at cross purposes. I understand your concern about luring attacks, John. I am sure you are right and they are feasible, but I interpreted Gary's comment as meaning 'closures can be used to build a more reliable sandbox'. But maybe this is not what is meant? kr, Yo John Steven wrote: 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
Re: [SC-L] Ajax one panel
thanks for the clarification, Gary. So I would like to restate my question as follows: do you know of any (atempts at) implementations of a sandbox based on closures? It seems to me that there are some tricky issues like how the permissions get into the closure or how privileged code is called. But that's probably due to the limitations on my imagination. Meanwhile, at Artima (http://www.artima.com/weblogs/viewpost.jsp?thread=161019) and ObjectMentor (http://blogs.objectmentor.com/ArticleS.MichaelFeathers.ItsTimeToDeprecateFinal), people are also discussing the 'final kludge', calling for 'final' to become deprecated. It would be nice to think there is something that could take its place :-) kr, Yo Gary McGraw wrote: You guys are both right, but talking about different things. You can kludge pretend closure for a security critical section using the static final nonsense to make a hole on the unbound environment. I described this in some detail in a 1999 javaworld article. Havung closure would lead to a better sandbox. The luring attacks that john describes were not what I was getting at, but they lend more weight to the argument for closure. Yay, language arcana! gem -Original Message- From: Johan Peeters [mailto:[EMAIL PROTECTED] Sent: Sun May 21 09:08:14 2006 To: John Steven Cc: Gary McGraw; Mailing List, Secure Coding; SSG Subject:Re: [SC-L] Ajax one panel We may be at cross purposes. I understand your concern about luring attacks, John. I am sure you are right and they are feasible, but I interpreted Gary's comment as meaning 'closures can be used to build a more reliable sandbox'. But maybe this is not what is meant? kr, Yo John Steven wrote: 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
