On Fri, Jul 25, 2008 at 10:23 AM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > Agreed! That's why I chose, in lieu of an argument to the contrary, not to > restore the value (tell me if this is the opposite of what you're saying > :)).
Breaking things is uncool. If we're overwriting window.opener with our own value, we should restore the original. > VBScript (COM, internally) objects, to the best of anyone's knowledge, do > not provide such a leak ie. isolate their calling context from their > receiver. That's true when accessed during JS execution. My hand-wavey > argument for this is that if COM objects allowed full access to their > creation context, COM would be fundamentally insecure, which I figure I'd > have heard about. But that's in no way definitive, of course, and again I'd > love to hear from someone who implemented IE or something for more. It's difficult to find an expert on VBScript to consult with on this stuff. I'm not sure there ever *were* experts, and anyone who was has long since moved on to greener pastures. Given the lack of real expertise, you're stuck with me using search engines. After a little digging, it turns out that VBScript does indeed support reflection: http://msdn.microsoft.com/en-us/library/zw39ybk8.aspx. Ball is in your court: tell me why this is secure even if VBScript objects allow introspection. > Not really. This is an optimization for gadgets.rpc, not fundamentally new > functionality. If the technique was found insecure, it would be removed. > Features built on gadgets.rpc would still work, just slower. This is a sketchy argument. Today people use gadgets.rpc for things that aren't latency sensitive. If we make it faster, we'll end up with products that require a fast gadgets.rpc implementation to be usable. If it turns out that NIX is insecure, we'll be stuck between a rock and a hard place. > The biggest concern is how to quickly roll out an rpc.js fix in this case. Yeah, this is interesting given the number of stake holders and the variety of deployments. The Apache foundation has a long history of managing vulnerabilities, and we can leverage some of that expertise to develop good policies around notifications and fixes. I'd be very interested in hearing from shindig deployers about how they want this to work. Cheers, Brian
