[tor-bugs] #24398 [Applications/Tor Browser]: Plugin-container exhausts memory leading to thrash and/or crash on Linux

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Nov 24 09:17:11 UTC 2017

#24398: Plugin-container exhausts memory leading to thrash and/or crash on Linux
     Reporter:  gk                   |      Owner:  tbb-team
         Type:  defect               |     Status:  new
     Priority:  Medium               |  Milestone:
    Component:  Applications/Tor     |    Version:
  Browser                            |   Keywords:  tbb-crash,
     Severity:  Normal               |  TorBrowserTeam201711R
Actual Points:                       |  Parent ID:
       Points:                       |   Reviewer:
      Sponsor:                       |
 We got a nice bugreport from a cypherpunk on our tbb-dev mailing list
 with a patch up for review (which I'll attach in a minute) (the problem
 seems to be caused by our workaround for #24052):

 1. Run one of the platforms affected by the recent "tormoil" vulnerability
    tested this on a GNU/Linux distro).

 2. Under Tor Browser 7.0.10's installation directory, create
    with the following content (you can use whatever you want here, just
    the next steps accordingly):

      body {
        background-color: blue !important;
        color: white !important;

 3. Start Tor Browser.

 4. Confirm that the content background looks blue.

 5. Right click the blue background on an empty spot (body element) and
    "Inspect Element".

 6. Wait until the Inspector window shows up.  Observe memory consumption
    process "plugin-container" continually rise.


 I think this regression is caused by the workaround [0] for the recent
 vulnerability [1], but it has exposed what looks to me (not being privy to
 details of "tormoil") like another bug, this one in javascript code.

   0: https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
   1: https://trac.torproject.org/projects/tor/ticket/24052

 `newChannelForURL` in DevToolsUtils.js (packed inside
 `Browser/browser/omni.ja`) will recursively call itself when
 `NetUtil.newChannel` raises an exception, prepending "file://" to the

    * Opens a channel for given URL. Tries a bit harder than
    * @param {String} url - The URL to open a channel for.
    * @param {Object} options - The options object passed to @method fetch.
    * @return {nsIChannel} - The newly created channel. Throws on failure.
   function newChannelForURL(url, { policy, window, principal }) {
     var securityFlags =

     let uri;
     try {
       uri = Services.io.newURI(url, null, null);
     } catch (e) {
       // In the xpcshell tests, the script url is the absolute path of the
       // file, which will make a malformed URI error be thrown. Add the
       // scheme to see if it helps.
       uri = Services.io.newURI("file://" + url, null, null);


     try {
       return NetUtil.newChannel(channelOptions);
     } catch (e) {
       // In xpcshell tests on Windows,
       // can throw NS_ERROR_UNKNOWN_PROTOCOL if the external protocol
       // supported by Windows, so we also need to handle the exception
 here if
       // parsing the URL above doesn't throw.
       return newChannelForURL("file://" + url, { policy, window, principal

 With the mentioned patch, the call to `NetUtil.newChannel` raises an
 exception.  This results in infinite recursion coupled with rapid (though
 linear) memory consumption.  Thus, `plugin-container` will, in just a few
 seconds, exhaust all available memory.

 Partial fix

 AFAICT, the current patch for "tormoil" is just a hurried stop-gap
 and as such it is acceptable, and somewhat expected, for it to cause
 less severe, kinds of breakage.  However, ISTM that the code in
 `newChannelForURL` is buggy regardless: the recursion has no (evident)
 termination condition.

 The comment before the recursive call says that it is needed due to some
 for which `newChannel` can raise `NS_ERROR_UNKNOWN_PROTOCOL`.  So maybe it
 should only catch the exception (and make the recursive call) if the error
 that one and `url` does not already start with "file://".  The attached
 does this.  It does not fix the regression (the Developer Toolbox still
 to show the appropriate styles and stylesheets), but at least fixes the
 caused by the runaway memory allocation.

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24398>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tor-bugs mailing list