#16874: https://sports.yahoo.com/dailyfantasy is broken with Tor Browser 5.0 on Windows -------------------------+------------------------------------------------- Reporter: gk | Owner: tbb-team Type: defect | Status: new Priority: normal | Milestone: Component: Tor | Version: Browser | Keywords: tbb-usability-website, Resolution: | tbb-5.0-regression, TorBrowserTeam201509 Actual Points: | Parent ID: Points: | -------------------------+-------------------------------------------------
Comment (by arthuredelstein): Replying to [comment:15 mikeperry]: > I'm unfamiliar with the new Services.scriptloader.loadSubScript API, but looking it up, it seems common for people to use https://developer.mozilla.org/en- US/docs/Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.Sandbox with it still, to cause the script to evaluate with content privileges.. > > Are you sure that what you did with XPCNativeWrapper.unwrap() instead is safe there? I don't why I had XPCNativeWrapper.unwrap() there -- I've removed it. > There's two main sources of risk when doing stuff like this: > 1. Adding Intl.js from chrome could cause the Intl.js expandos to actually have chrome privileges inside the content window. This seems unlikely, but again I'm not sure. > 2. The polyfill itself may be running with chrome privs when installing itself, which means that if it touches an unwrapped window property, it may be induced to execute content code (in the form of a getter/setter, perhaps) that way, in a privileged setting. The documentation at https://developer.mozilla.org/en- US/docs/Mozilla/Tech/XPCOM/Reference/Interface/mozIJSSubScriptLoader#loadSubScript%28%29 claims that "The loaded script is executed with the principal associated with the target object." So that's at least promising. First I confirmed that the principal for the contentWindow object is non- chrome: {{{ > Components.utils.getObjectPrincipal(gBrowser.selectedBrowser.contentWindow) XPCWrappedNative_NoHelper { URI: XPCWrappedNative_NoHelper, origin: "https://arthuredelstein.github.io";, jarPrefix: "", baseDomain: "arthuredelstein.github.io", appStatus: 0, appId: 0, isInBrowserElement: false, unknownAppId: false, isNullPrincipal: false } }}} Then for a more direct test, I added the line {{{ console.log("Components.interfaces:", Components.interfaces); }}} to the top of Intl.js. In that case, every loaded page logs an error: {{{ ReferenceError: Components is not defined }}} I didn't immediately think of any further tests that might approach the question in another way. > For some reason, I can't seem to find any documentation on either of these risks. Perhaps that's because this new API is magically safe no matter how you use it? Maybe this is a question for #security on irc.mozilla.org, and/or some testing? You're right that we should be very careful about this. I've posted a question there. In the meantime, here's the new version without XPCNativeWrapper.unwrap: https://github.com/arthuredelstein/torbutton/commit/16874+2 I suppose one alternative would be to insert a `<SCRIPT src="resource://...">` element to the content page's DOM once it has started loading. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16874#comment:16> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
