12107 2007-01-03 18:03:33 -0800 Security Regression: Plugins load remote javascript in embedded page's context 2007-03-12 01:21:55 -0700 1 1 1 Unclassified WebKit Plug-ins 420+ Mac OS X 10.4 RESOLVED WONTFIX http://landonf.bikemonkey.org/static/moab-tests/hreftrack.html InRadar, Regression P1 Major --- 1 webkit-bugs webkit-unassigned ddkilzer dev+webkit dstorey ggaren KwhiteRight mrowe rachael troyb oldest_to_newest 37257 0 webkit-bugs 2007-01-03 18:03:33 -0800 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. 37221 1 ggaren 2007-01-03 22:35:22 -0800 Using the latest nightly, I don't see a dialog. 37203 2 webkit-bugs 2007-01-04 00:17:17 -0800 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. 37171 3 ddkilzer 2007-01-04 04:36:34 -0800 (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). 37169 4 ddkilzer 2007-01-04 04:57:58 -0800 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. 37160 5 ddkilzer 2007-01-04 05:00:41 -0800 (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). 37167 6 ddkilzer 2007-01-04 06:02:33 -0800 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); } 37151 7 ddkilzer 2007-01-04 06:55:27 -0800 (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. 37149 8 ddkilzer 2007-01-04 08:13:40 -0800 (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. 37148 9 dstorey 2007-01-04 09:04:28 -0800 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. 37138 10 ddkilzer 2007-01-04 10:57:21 -0800 (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. 37130 11 dstorey 2007-01-04 11:24:59 -0800 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. 34598 12 mrowe 2007-01-16 19:35:56 -0800 <rdar://problem/4928683> 25277 13 webkit-bugs 2007-02-07 03:53:41 -0800 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. 19463 14 mrowe 2007-03-12 01:21:55 -0700 The radar has been marked as Behaves Correctly. Closing this bug as WONTFIX to reflect that.