Security Regression: Plugins load remote javascript in embedded page's context

[Rosyna]

Look at http://landonf.bikemonkey.org/static/moab-tests/hreftrack.html it shows a dialog on ToT that has the header of "http://landonf.bikemonkey.org" However, the plugin is loading a movie from gnucitizen. The dialog should say http://www.gnucitizen.org/ as the header.

This is NOT a QuickTime bug, this is a WebKit bug as WebKit (well, JavaScriptCore) runs the JavaScript from the plugin.

[Geoffrey Garen]

Using the latest nightly, I don't see a dialog.

[Rosyna]

Occurs for me in ToT. Note, you might have to remove third party QuickTime components (such as those for watching pornography or episodes of torchwood) so the correct handler gets to handle it in the QT plugin.

[David Kilzer (:ddkilzer)]

(In reply to comment #1)
> Using the latest nightly, I don't see a dialog.

I am able to see the JavaScript dialog in a locally-built debug build of WebKit r18574 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127) with QuickTime 7.1.3 installed (with QuickTime Pro registered).

[David Kilzer (:ddkilzer)]

Additional browser testing (in no particular order) on my PowerBook G4 with 10.4.8 (8L127):

Firefox 2.0.0.1 shows the JavaScript dialog.
Mac IE 5.2.3 (5815.1) does NOT show the dialog.
OmniWeb 5.5.1 (v607.5) shows the JavaScript dialog.
Opera 9.10 (build 3588) shows the JavaScript dialog AND opens up a new tab with about:blank as the contents.
Mozilla 1.7.13 shows the JavaScript dialog.

[David Kilzer (:ddkilzer)]

(In reply to comment #1)
> Using the latest nightly, I don't see a dialog.

I am able to reproduce this with WebKit nightly r18554 as well with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127).

[David Kilzer (:ddkilzer)]

Tracing through WebKit while loading hreftrack.html, I found that [WebPluginController webPlugInContainerLoadRequest:inFrame:] in WebKit/Plugins/WebPluginController.mm appears to be the weak link (where the JavaScript from the QuickTime movie on another site is implicitly trusted and run in the current frame's context).

I've added a FIXME comment below where I think this should happen:

    NSString *JSString = [[request URL] _webkit_scriptIfJavaScriptURL];
    if (JSString) {
        if ([frame findFrameNamed:target] != frame) {
            LOG_ERROR("JavaScript requests can only be made on the frame that contains the plug-in");
            return;
        }
        // FIXME: Verify domain of QuickTime (or other) object matches domain of current frame
        [[frame _bridge] stringByEvaluatingJavaScriptFromString:JSString];
    } else {
        if (!request) {
            LOG_ERROR("could not load URL %@", [request URL]);
            return;
        }
        [frame _frameLoader]->load(request, target);
    }

[David Kilzer (:ddkilzer)]

(In reply to comment #6)
> Tracing through WebKit while loading hreftrack.html, I found that
> [WebPluginController webPlugInContainerLoadRequest:inFrame:] in
> WebKit/Plugins/WebPluginController.mm appears to be the weak link (where the
> JavaScript from the QuickTime movie on another site is implicitly trusted and
> run in the current frame's context).

Unfortunately, I'm not sure if it's possible for WebKit to "know" where the plug-in content came from since the QuickTime plugin is responsible for loading the content.  As Landon notes in his MOAB #3 blog entry, he had to patch QuickTime plug-in's nNPN_GetURL() method to do the check.

http://landonf.bikemonkey.org/code/macosx/MOAB_Day_3.20070104063131.4037.zadder.local.html

Of course any plug-in could do the same thing--pull JavaScript from anywhere and pass it to WebKit to execute in the local context.

[David Kilzer (:ddkilzer)]

(In reply to comment #7)
> Unfortunately, I'm not sure if it's possible for WebKit to "know" where the
> plug-in content came from since the QuickTime plugin is responsible for loading
> the content.  As Landon notes in his MOAB #3 blog entry, he had to patch
> QuickTime plug-in's nNPN_GetURL() method to do the check.

On second thought, if the plug-in is well-behaved (e.g., it doesn't implement its own URL loader internally), a taint-checking flag (say HasLoadedExternalResources) could be set whenever the plug-in requests a resource outside of the original domain/hostname.  This flag could then be checked before executing any JavaScript from the plug-in.

[David Storey]

Thanks for CC'ing me.  I've reported this as Bug 246168 in out BTS.  I'll keep you posted with any relevant info from our end.

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> Additional browser testing (in no particular order) on my PowerBook G4 with
> 10.4.8 (8L127):

And just for fun on Windows XP SP2 [Version 5.1.2600] with iTunes 7.0.2.16 and QuickTime for Windows 7.1.3:

MSIE 6 (Version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519) shows the JavaScript dialog.

[David Storey]

After a quick check, we (Opera) seem to have handled this the same way as the currently released Safari in the past, but changed behaviour to how ToT, FF, IE etc handle it as it broke a lot of sites.  We could probably handle things a bit differently though to avoid phishing issues.  

[Mark Rowe (bdash)]

<rdar://problem/4928683>

[Rosyna]

The problem isn't that webkit (or any browser) shows the dialog. The problem (en masse) is the domain the browser says the dialog is from. Many, many Web browsers have labeled the domain in which a dialog comes from after a flaw in the way dialogs was shown was found across browsers.

Due to the labeling, showing a dialog is the easiest way to determine if a browser is susceptible to the bug.

[Mark Rowe (bdash)]

The radar has been marked as Behaves Correctly.  Closing this bug as WONTFIX to reflect that.