[
https://issues.apache.org/jira/browse/SHINDIG-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621944#action_12621944
]
John Hjelmstad commented on SHINDIG-416:
----------------------------------------
Update: I and others have been poking around to find some (any! :)) VBScript
expertise to further vet the security of this approach. We've discovered that
it seems the security of this approach hinges on IDispatchEx in IE's scripting
engine. Both the JScript engine and the VBScript engine will try to talk to
that interface on any object that supports it and will pass in the current
script engine's context as the service provider pointer. It's then up to the
object to figure out whether it wants to let the call succeed or not based on
whatever the service provider tells it. When JScript talks to intrinsic
objects, like strings, it doesn't use IDispatchEx since those objects don't
bother to support it - hence the ability to get the window object across
domains - although I don't think the new frame could access properties on the
window object (which does support IDispatchEx).
In the NIX case, the VBScript object serves as a gate-keeper between the
domains. The creator domain creates the VBScript object as a wrapper around
some data passed in from JScript. At that point what's important is the detail
of what was pushed into the VBScript object. If a string is pushed in from
JScript, it should be fine because that will be passed as a BSTR into the
VBScript object. If an object or a function were passed into VBScript, then an
IDispatch(Ex) pointer will get into VBScript. When the new frame reads it out
of VBScript, the IDispatch(Ex) pointer could make it into the new frame - at
which point it might be possible to access things like
toString.constructor(...) on that object.
But NIX passes only Strings, not JScript objects, into the VBScript wrapper.
All function calls are proxied, and the only params passed and objects returned
by the wrapper class are either primitives (string, ints, et. al) and other
wrappers. So this ensures that the other context's JScript remains walled-off
by the VBScript wrapper and therefore not leaked. An attacker would need to
somehow break the private encapsulation of the VBScript object to access the
internal context.
As such, the only remaining theoretical question-mark is VBScript's Eval
function. If the frame could get access to this method and pass it some
VBScript, that script may execute in the VBScript's domain and if it could then
get to the JScript context it would be able to access anything it wanted
because it was in the original domain. There are at least 2 "if" clauses in
that statement, though, and neither I nor anyone else have yet to see a way to
call Eval on a specific call/context (i.e. execute it inside of the VBScript
class).
> Implement window.opener-based IE transport ("NIX") in gadgets.rpc
> -----------------------------------------------------------------
>
> Key: SHINDIG-416
> URL: https://issues.apache.org/jira/browse/SHINDIG-416
> Project: Shindig
> Issue Type: Improvement
> Components: Features (Javascript)
> Reporter: John Hjelmstad
> Assignee: John Hjelmstad
> Attachments: rpc.js.patch
>
>
> Joey Schorr and I have been developing a technique for high-speed
> cross-domain message passing in IE6 and IE7 that exploits an odd property:
> for a given window object, window.opener can be set by any party, but only
> read by the controlling window.
> The message-passing technique is to pass a "channel creation" object from the
> container, across domain boundaries, to the gadget. The gadget uses this
> object to establish a bi-directional communication channel used by all
> subsequent gadgets.rpc calls.
> We can't pass a JavaScript object through window.opener, however, because
> doing so enables access to the passing agent's full window context. Eg. if
> the container sets window.opener = function() { ... }, then the gadget can
> access the entire container page with:
> var containerWindow = (new window.opener.constructor("return window;"))();
> Instead, we pass a VBScript (COM) wrapper through window.opener, since COM
> objects don't have this property. The gadget passes back such a wrapper as
> well, ensuring mutually isolated contexts.
> Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
