Opened 8 years ago

Closed 4 years ago

Last modified 9 months ago

#2874 closed enhancement (fixed)

Block access to Components.interfaces from content script

Reported by: mikeperry Owned by: mikeperry
Priority: Medium Milestone:
Component: Firefox Patch Issues Version:
Severity: Blocker Keywords: MikePerryIterationFires20110529, backport-to-mozilla, MikePerry201408R, tbb-no-uplift-60
Cc: g.koppen@…, lunar@…, arthuredelstein@…, boklm Actual Points: 1
Parent ID: Points: 4
Reviewer: Sponsor:

Description

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

Child Tickets

Attachments (2)

Screen Shot 2014-08-09 at 12.08.15 AM.png (149.1 KB) - added by arthuredelstein 4 years ago.
0001-fixup-Bug-2874.-Remove-the-Components-shim-introduce.patch (12.3 KB) - added by arthuredelstein 4 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 8 years ago by mikeperry

Type: defectenhancement

comment:2 Changed 8 years ago by gk

Cc: g.koppen@… added

comment:3 Changed 8 years ago by mikeperry

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

comment:4 Changed 8 years ago by mikeperry

Points: 4

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.

comment:5 Changed 8 years ago by mikeperry

Component: Tor bundles/installationTor Browser

comment:6 Changed 8 years ago by lunar

Cc: lunar@… added

comment:7 Changed 8 years ago by mikeperry

Keywords: MikePerryIterationFires20110529 added

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

comment:8 Changed 8 years ago by mikeperry

Patch for this lives in #2873.

comment:9 Changed 8 years ago by mikeperry

Actual Points: 1
Resolution: fixed
Status: newclosed
Summary: Block or mark Components.interfaces configurableBlock access to Components.interfaces from content script

comment:10 Changed 7 years ago by StrangeCharm

Keywords: backport-to-mozilla added

comment:11 Changed 4 years ago by arthuredelstein

Parent ID: #2871
Resolution: fixed
Status: closedreopened

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.)

comment:12 Changed 4 years ago by arthuredelstein

Cc: arthuredelstein@… added

comment:13 Changed 4 years ago by boklm

Cc: boklm added

Changed 4 years ago by arthuredelstein

comment:14 Changed 4 years ago by arthuredelstein

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,

comment:15 Changed 4 years ago by arthuredelstein

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.

Last edited 4 years ago by arthuredelstein (previous) (diff)

comment:16 Changed 4 years ago by arthuredelstein

Keywords: MikePerry201408R added
Status: reopenedneeds_review

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.

comment:17 Changed 4 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

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!

comment:18 Changed 9 months ago by arthuredelstein

Keywords: tbb-no-uplift-60 added
Severity: Blocker

Not uplifting for ESR60 because Mozilla is hasn't decided to remove it yet, and is still collecting telemetry.

Note: See TracTickets for help on using tickets.