On Fri, Jul 25, 2008 at 10:23 AM, John Hjelmstad <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 25, 2008 at 9:53 AM, Brian Eaton <[EMAIL PROTECTED]> wrote:
>
> > I'm more interested in avoiding breakage in gadgets that read
> > window.opener. Writing to window.opener is an obscene hack, we
> > shouldn't support gadgets that do that kind of crazy stuff. =)
>
>
> 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
> :)).
>
>
> >
> >
> > (BTW - have I mentioned that you might be the first person in history
> > to say "It's secure because it uses VBScript"?)
>
>
> That may well be my favorite property about this hack :)
>
>
> >
> >
> > Let me see if I understand where we're at on this...
> >
> > - We think we have an authentication protocol that works, based on the
> > notion that window.opener is a same-origin prototected write-only
> > property similar to document.location. We don't have proof that
> > window.opener is being protected by the same-origin policy, but it
> > seems like a reasonable assumption given the tests we've performed.
> >
>
> Yes, re: authentication protocol. It's hard to say what constitutes proof
> of
> window.opener's write-only policy beyond testing, but I'd love to hear from
> someone who knows the innards of IE.
>
>
> >
> >
> > - We are aware of problems involving leaking javascript context across
> > domains. We're dealing with those problems using VBScript wrappers on
> > the assumption that VBScript does not support reflection. (Why do we
> > believe that, by the way? Mike Samuel pointed out that VBScript
> > descends from COM, which was all about reflection...)
>
>
> Well, my terminology on this one isn't great, but to state in the terms
> I've
> been using, we're aware that any JS object leaks the full context in which
> it is created. The syntax highlighting this is as follows, for function
> 'fn':
> var fnsWindow = (new fn.constructor("return window;"))();
>
> This extends to an arbitrary object through prototype and built-in
> functions.
>
> 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.
COM (on win32) is fundamentally insecure (or rather, it doesn't have any
security model of its own), which is why systems that use it almost always
provide an additional security layer on top of it.
The biggest problem with COM is that it's designed to support any old
version of an API indefinitely, which means that once a compromised version
of a COM library exists on a system, even updating to a newer version can
leave you vulnerable. You can't trust "the security of COM", you have to
know that the specific COM library you're using (and the specific version,
for that matter) is secure.
Now, mind you, COM is just a generic model for writing highly modular C code
("The Component Object Model"). It isn't something fundamentally associated
with IE in particular or VBScript in particular, but MS uses their
implementation heavily throughout all of win32. What you're trusting in here
is that the COM objects tied to the VBScript objects have been properly
secured at the boundaries. Given the relatively tiny amount of VBScript out
there, I'd suspect that the language itself has probably gone under a lot
less scrutiny than JScript has.
In other words, I still find the whole thing highly suspect, but if Brian
feels comfortable with it then I'm OK with it as well, because I'll just
blame him for saying it was OK :).
>
>
>
> >
> >
> > - We're prepared to build applications that rely on this change, and
> > then break those applications if someone discovers that window.opener
> > is not as secure as we'd hoped.
>
>
> 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.
>
> The biggest concern is how to quickly roll out an rpc.js fix in this case.
>
> --John
>
>
> >
> >
> > Cheers,
> > Brian
> >
> > On Thu, Jul 24, 2008 at 5:57 PM, John Hjelmstad <[EMAIL PROTECTED]>
> wrote:
> > > No, mostly beacuse there's no legitimate use for setting window.opener
> in
> > IE
> > > when rendering a gadget IFRAME at this point, as far as I know.
> > >
> > > That said, the library could be used pretty directly (or adapted to do
> > the
> > > same), so I'd be happy to add it if you think it's important.
> > >
> > > John
> > >
> > > On Thu, Jul 24, 2008 at 5:54 PM, Brian Eaton <[EMAIL PROTECTED]>
> wrote:
> > >
> > >> Quick functionality check: does this restore window.opener to it's
> > >> original value after working it's evil magic?
> > >>
> > >> On Thu, Jul 24, 2008 at 4:44 PM, John Hjelmstad <[EMAIL PROTECTED]>
> > wrote:
> > >> > All,
> > >> >
> > >> > As commented in http://issues.apache.org/jira/browse/SHINDIG-416,
> to
> > the
> > >> > best of my knowledge all security concerns with the IE
> > >> window.opener-based
> > >> > technique have been resolved. The patch works and is very fast,
> > >> significant
> > >> > benefits atop which we can build lots of cool functionality IMHO. As
> > >> such,
> > >> > I'm inclined to commit this patch.
> > >> >
> > >> > But I want to tread very cautiously, so I'm putting out a call for
> > >> dissent.
> > >> > Does anyone object to committing this? Are there any specific
> security
> > >> > concerns or unaccounted-for attack vectors?
> > >> >
> > >> > Thanks,
> > >> > John
> > >> >
> > >>
> > >
> >
>
