Block access to Components.interfaces from content script

Components.interfaces can be used to fingerprint browser user agent down to OS and minor version. This might not be a lot of data for fingerprinting (depending on how well we keep users upgraded), but it certainly is a concern for targeting exploit payloads against a particular OS and version combo.

Here's an (outdated) PoC: http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html

Here's the Firefox bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=429070

added MikePerry201408R MikePerryIterationFires20110529 actualpoints::1 backport-to-mozilla component::firefox patch issues owner::mikeperry points::4 priority::medium resolution::fixed severity::blocker status::closed tbb-no-uplift-60 type::enhancement labels

Trac:
Type: defect to enhancement

Trac:
Cc: N/A to g.koppen@jondos.de

FYI, here is the Firefox bug corresponding to this, but I think we should handle this issue using ECMAScript 5 hooking. https://bugzilla.mozilla.org/show_bug.cgi?id=429070

Blocking and/or changing the attribute of this should be simple. Will of course need to be tested though. Also, some research on why a website might actually need this to function properly is probably a good plan.

Trac:
Points: N/A to 4

Trac:
Component: Tor bundles/installation to Tor Browser

Trac:
Cc: g.koppen@jondos.de to g.koppen@jondos.de, lunar@debian.org

If I am doing #2873 (closed), might as well do this. It is basically the same change.

Trac:
Keywords: N/A deleted, MikePerryIterationFires20110529 added

Patch for this lives in #2873 (closed).

Trac:
Resolution: N/A to fixed
Actualpoints: N/A to 1
Status: new to closed
Summary: Block or mark Components.interfaces configurable to Block access to Components.interfaces from content script

Trac:
Keywords: N/A deleted, backport-to-mozilla added

In trying to rebase this patch to ESR31, I discovered that it's still possible to access Components.interfaces from content scripts.

Here is a demo. Try with TorBrowser 3.6.3 and JavaScript active. https://arthuredelstein.github.io/tordemos/bug2874.html

Also works with latest version of Firefox. (I presume with ESR31 as well.)

Trac:
Resolution: fixed to N/A
Parent: #2871 (closed) to N/A
Status: closed to reopened

Trac:
Cc: g.koppen@jondos.de, lunar@debian.org to g.koppen@jondos.de, lunar@debian.org, arthuredelstein@gmail.com

Trac:
Cc: g.koppen@jondos.de, lunar@debian.org, arthuredelstein@gmail.com to g.koppen@jondos.de, lunar@debian.org, arthuredelstein@gmail.com, boklm

Trac:

In Mozilla bug 790732, Components.interfaces was converted to a "lazily-resolved shim". I was able to confirm that this shim code in ESR31 exactly matches the Components.interfaces object I observed in my demo in comment:11:

Moreover, a comment points out that the fix of 790732 resolved 429070 ("exposing Components.interfaces to untrusted content leaks information about installed extensions") because "...we only shim interfaces that expose DOM constants (see kInterfaceShimMap in nsDOMClassInfo.cpp), which is the same for everyone."

So assuming that's correct, I think we don't need to port this patch to ESR31. There is still the question of how to block Components.interfaces for the ESR24 branch of TB,

In Mozilla bug 790732, Components.interfaces was converted to a "lazily-resolved shim". I was able to confirm that this shim code in ESR31 exactly matches the Components.interfaces object I observed in my demo in comment:11:

Moreover, a comment points out that the fix of 790732 resolved 429070 ("exposing Components.interfaces to untrusted content leaks information about installed extensions") because "...we only shim interfaces that expose DOM constants (see kInterfaceShimMap in nsDOMClassInfo.cpp), which is the same for everyone."

So assuming that's correct, I think we don't need to port this patch to ESR31. There is still the question of how to block Components.interfaces for the ESR24 branch of TB.

Trac:
0001-fixup-Bug-2874.-Remove-the-Components-shim-introduce.patch

Components.interfaces has a different set of properties in ESR31 and ESR24. So I've reconsidered, and I think it's cleaner if we remove the Components.interfaces object from both ESR24 and ESR31 branches. That way, Components.interfaces won't be a method for content scripts to distinguish different versions of TorBrowser. I'm attaching a patch here that removes Components.interfaces for ESR24, and I'll be providing a similar patch to ESR31 for #12620 (moved).

Trac:
Keywords: N/A deleted, MikePerry201408R added
Status: reopened to needs_review

Ok, this is merged in both the 3.x and 4.x branches. It looks like it gets all of Components.*, too, which is nice. Thanks!

Trac:
Status: needs_review to closed
Resolution: N/A to fixed