[tor-bugs] #16874 [Tor Browser]: https://sports.yahoo.com/dailyfantasy is broken with Tor Browser 5.0 on Windows

[Tor Bug Tracker & Wiki]

#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