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