Bug 12107 - Security Regression: Plugins load remote javascript in embedded page's context
: Security Regression: Plugins load remote javascript in embedded page's context
Status: RESOLVED WONTFIX
Product: WebKit
Classification: Unclassified
Component: Plug-ins
: 420+
: Macintosh OS X 10.4
: P1 Major
Assigned To: Nobody
http://landonf.bikemonkey.org/static/...
: InRadar, Regression
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-03 18:03 PST by Rosyna
Modified: 2007-03-12 01:21 PDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rosyna 2007-01-03 18:03:33 PST
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.
Comment 1 Geoffrey Garen 2007-01-03 22:35:22 PST
Using the latest nightly, I don't see a dialog.
Comment 2 Rosyna 2007-01-04 00:17:17 PST
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.
Comment 3 David Kilzer (:ddkilzer) 2007-01-04 04:36:34 PST
(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).

Comment 4 David Kilzer (:ddkilzer) 2007-01-04 04:57:58 PST
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.

Comment 5 David Kilzer (:ddkilzer) 2007-01-04 05:00:41 PST
(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).

Comment 6 David Kilzer (:ddkilzer) 2007-01-04 06:02:33 PST
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);
    }
Comment 7 David Kilzer (:ddkilzer) 2007-01-04 06:55:27 PST
(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.

Comment 8 David Kilzer (:ddkilzer) 2007-01-04 08:13:40 PST
(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.

Comment 9 David Storey 2007-01-04 09:04:28 PST
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.
Comment 10 David Kilzer (:ddkilzer) 2007-01-04 10:57:21 PST
(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.
Comment 11 David Storey 2007-01-04 11:24:59 PST
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.  
Comment 12 Mark Rowe (bdash) 2007-01-16 19:35:56 PST
<rdar://problem/4928683>
Comment 13 Rosyna 2007-02-07 03:53:41 PST
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.
Comment 14 Mark Rowe (bdash) 2007-03-12 01:21:55 PDT
The radar has been marked as Behaves Correctly.  Closing this bug as WONTFIX to reflect that.