about NoScript::ScriptSurrogate compartments

[milithruldur]

I only recently started paying attention to compartments since Mozilla made frontends such as about:memory and about:compartments available in recent Firefox releases.

I notice in about:compartments under [System Compartments] such entries as:

Code: Select all

[System Principal], NoScript::ScriptSurrogate@about: (from: chrome://noscript/content/ScriptSurrogate.js:244)
[System Principal], NoScript::ScriptSurrogate@about:compartments (from: chrome://noscript/content/ScriptSurrogate.js:244) [3]
[System Principal], NoScript::ScriptSurrogate@about:memory (from: chrome://noscript/content/ScriptSurrogate.js:244)

My question is that should NS surrogates be running within these internal URIs such as the ones from above? I also found out that some internal URIs do not trigger this sandboxing (took a quick look from the js that was referenced) from NS, such as about:robots or about:config. Are there exceptions to this, if it is indeed necessary for NS to be running surrogates from such URIs?

I understand surrogates provided by NS as a workaround for broken web functions from websites where scripts are prohibited to run. But I find it unusual that surrogates should be running within internal URIs, seeing as default NS surrogate templates from about:config only provide workarounds for some popular sites.

[Thrawn]

The point of surrogates is to run when scripts are blocked, so they can't run within the page context, or they too would be blocked. And they aren't meant to do anything except provide dummy values to prevent script errors, so there shouldn't be any security risk by running them in chrome context.

Is there a specific problem with surrogates running as chrome://? What sandboxing are you referring to?

[milithruldur]

Is there a specific problem with surrogates running as chrome://?

There isn't any yet that I know so far, it's just that I took notice of it, knowing that surrogates in NS, as far as I can tell, were created to workaround breakages in webpages where scripts are blocked. So I find it unsual that surrogates should also be running inside internal URIs if it does nothing there, assuming it does nothing, and not to mention it is an unecessary use of memory resource.

Actually I was trying to reliably replicate a possible memory leak manifested via ghost windows/zombie compartments while running NS and Ghostery together apparently, even after creating a new profile with just the two aforementioned addons. And I thought to ask about why surrogates are running inside internal URIs as well.

What sandboxing are you referring to?

Code: Select all

chrome://noscript/content/ScriptSurrogate.js:

 _sandboxParams: {
    wantXrays: false,
    sandboxName: ""
  },
executeSandbox: function(document, scriptBlock, env) {
    var w = document.defaultView;
    try {
      if (typeof w.wrappedJSObject === "object") w = w.wrappedJSObject;
      this._sandboxParams.sandboxName = "NoScript::ScriptSurrogate@" + document.URL;
      this._sandboxParams.sandboxPrototype = w;
      let s = new Cu.Sandbox(w, this._sandboxParams);   // <---- Line 244 ----<< //
      if (!("top" in s)) s.__proto__ = w;
      if (typeof env !== "undefined") {
        s.env = env;
        let ep = {};
        for (let p in env) {
          ep[p] = "rw";
        }
        env.__exposedProps__ = ep;
      }
      let code = "with(window){" + scriptBlock + "}delete this.env;";
      if ("keys" in Object) code += "for each(let p in Object.keys(this))window[p]=this[p];";
      Cu.evalInSandbox(code, s, this.JS_VERSION);
    } catch (e) {
      if (ns.consoleDump) {
        ns.dump(e);
        ns.dump(scriptBlock);
      }
      if (this.debug) Cu.reportError(e);
    } finally {
      delete this._sandboxParams.sandboxPrototype;
    }
  },

[dhouwn]

I brought this up before, I guess the overhead is simply negligible.

[milithruldur]

I brought this up before, I guess the overhead is simply negligible.

Thanks, it helped to know some background regarding the surrogates mechanism.