Re: SHINDIG-416 (optimized IE relayless gadgets.rpc technique): concerns?

[John Hjelmstad <fa...@google.com>]

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 <be...@google.com> 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 <fa...@google.com> 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
> >
>

Re: SHINDIG-416 (optimized IE relayless gadgets.rpc technique): concerns?

[John Hjelmstad <fa...@google.com>]

* restoring window.opener: Fair enough, I'll add this.

* VBScript objects supporting reflection/introspection: this may be so, but
the salient property as far as I see it is that they don't leak their source
creation context ie. the sender's window. This, combined with window.opener
being write-only (so that the MITM attack surmised earlier in this long
discussion isn't feasible), gives me a reasonable amount of confidence in
the technique. But as aforementioned, I can't definitively prove this, as
I'm in the same boat as the vast majority of others in not being a VBScript
"expert."

* Building stuff atop fast cross-domain functionality: Yeah, I suppose it's
a different class of functionality we're discussing here, so this technique
is fundamental to enabling it.

* Pushing out patches for vulnerabilities: I'd also be interested to hear
others' thoughts on how this ought to be managed within Shindig's suite of
deployments. This problem is a wider one than just pertaining to rpc.js.

In sum, I'm still confident (though cautiously so) in the technique, and
think it's worthy enough (reward/risk ratio) to go forward. Thoughts?

John

On Mon, Jul 28, 2008 at 10:51 AM, Michael Ryan (Software Developer) <
Michael.Ryan@apollogrp.edu> wrote:

>
> > -----Original Message-----
> > From: Brian Eaton [mailto:beaton@google.com]
> >
> > Yes.  Several people have written javascript fuzzers and made various
> > javascript engines crash and burn, but a lot of that research only
> > happened in the past couple of years.  VBScript is nearly as
> > omnipresent, but has received less attention.  I suspect it would be
> > fertile ground.  Maybe Microsoft has done the work to harden VBScript
> > internally.  It's hard to tell.
>
>
> Afaik, Jscript and VBScript internals share a lot of things wrt the
> browser interfaces, and objects available.  Since both runtime engines
> use COM in very similar ways...  If you can't instantiate a COM object
> through "new ActiveXObject('id')" in JS, you probably can't in VBS
> either.
>
> The scripting engines don't themselves provide storage access, this
> Is done via COM libraries, which generally aren't marked as safe for
> Scripting in a browser...  The JET/Access connector was for a while,
> Which was used by some scripted attacks.
>
> Other than this, and some issues with Flash's engine (especially
> earlier versions), it's been relatively stable.  Personally, I don't
> see much point of VBS.... and never really cared for it.
>
> --
> Michael J. Ryan  --  Software Developer  --  Apollo Group
>
> This message is private and confidential. If you have received it in error,
> please notify the sender and remove it from your system.
>

RE: SHINDIG-416 (optimized IE relayless gadgets.rpc technique): concerns?

["Michael Ryan (Software Developer)" <Mi...@apollogrp.edu>]

> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
>
> Yes.  Several people have written javascript fuzzers and made various
> javascript engines crash and burn, but a lot of that research only
> happened in the past couple of years.  VBScript is nearly as
> omnipresent, but has received less attention.  I suspect it would be
> fertile ground.  Maybe Microsoft has done the work to harden VBScript
> internally.  It's hard to tell.


Afaik, Jscript and VBScript internals share a lot of things wrt the 
browser interfaces, and objects available.  Since both runtime engines 
use COM in very similar ways...  If you can't instantiate a COM object 
through "new ActiveXObject('id')" in JS, you probably can't in VBS 
either.

The scripting engines don't themselves provide storage access, this 
Is done via COM libraries, which generally aren't marked as safe for 
Scripting in a browser...  The JET/Access connector was for a while, 
Which was used by some scripted attacks.

Other than this, and some issues with Flash's engine (especially 
earlier versions), it's been relatively stable.  Personally, I don't 
see much point of VBS.... and never really cared for it.

-- 
Michael J. Ryan  --  Software Developer  --  Apollo Group

This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

Re: SHINDIG-416 (optimized IE relayless gadgets.rpc technique): concerns?

[Brian Eaton <be...@google.com>]

On Fri, Jul 25, 2008 at 10:37 AM, Kevin Brown <et...@google.com> wrote:
> 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.

Yes.  Several people have written javascript fuzzers and made various
javascript engines crash and burn, but a lot of that research only
happened in the past couple of years.  VBScript is nearly as
omnipresent, but has received less attention.  I suspect it would be
fertile ground.  Maybe Microsoft has done the work to harden VBScript
internally.  It's hard to tell.

> 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 :).

Heh. =)

Re: SHINDIG-416 (optimized IE relayless gadgets.rpc technique): concerns?

[Kevin Brown <et...@google.com>]

On Fri, Jul 25, 2008 at 10:23 AM, John Hjelmstad <fa...@google.com> wrote:

> On Fri, Jul 25, 2008 at 9:53 AM, Brian Eaton <be...@google.com> 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 <fa...@google.com>
> 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 <be...@google.com>
> 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 <fa...@google.com>
> > 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
> > >> >
> > >>
> > >
> >
>

Re: SHINDIG-416 (optimized IE relayless gadgets.rpc technique): concerns?

[Brian Eaton <be...@google.com>]

On Fri, Jul 25, 2008 at 10:23 AM, John Hjelmstad <fa...@google.com> 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

Re: SHINDIG-416 (optimized IE relayless gadgets.rpc technique): concerns?

[John Hjelmstad <fa...@google.com>]

On Fri, Jul 25, 2008 at 9:53 AM, Brian Eaton <be...@google.com> 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.


>
>
> - 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 <fa...@google.com> 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 <be...@google.com> 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 <fa...@google.com>
> 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
> >> >
> >>
> >
>

Re: SHINDIG-416 (optimized IE relayless gadgets.rpc technique): concerns?

[Brian Eaton <be...@google.com>]

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. =)

(BTW - have I mentioned that you might be the first person in history
to say "It's secure because it uses VBScript"?)

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.

- 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...)

- 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.

Cheers,
Brian

On Thu, Jul 24, 2008 at 5:57 PM, John Hjelmstad <fa...@google.com> 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 <be...@google.com> 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 <fa...@google.com> 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
>> >
>>
>