Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#22966 closed defect (duplicate)

Nasty MitM possibility with the Firefox blocklist service

Reported by: basvd Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords:
Cc: yawning Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Once a day the Firefox/Tor browser will do a call to the Firefox blocklist service. The URL of this endpoint is (extensions.blocklist.url):

https://blocklists.settings.services.mozilla.com/v1/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/%TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/

Example:

https://blocklist.addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/52.2.0/Firefox/20170202030101/WINNT_x86-gcc3/en-US/release/Windows_NT%2010.0/default/default/34/34/1/

1) The browser suppresses bad certificate errors on this URL
The Firefox blocklist service suppresses bad certificates errors while downloading the blocklist.xml. In this way it is quite easy to setup a MitM attack and remove revoked certificates from the blocklist.xml

Proof of concept;

  • Run a webserver listening to https://blocklists.settings.services.mozilla.com
  • Create a fake blocklist XML (/v1/blocklist/etc...)
  • Add 12.34.56.78 blocklists.settings.services.mozilla.com to your host file
  • Reset app.update.lastUpdateTime.blocklist-background-update-timer and change extensions.blocklist.interval
  • Wait until Tor calls these blocklist service.
  • Check the blocklist.xml inside the Tor installation folder

2) Mozilla is able to see Tor user specific information:
There is a lot of OS/platform/browser specific information in the URL. So Mozilla has a lot of statistics about the Tor browser usage. Not necessary IMHO.

APP_ID
APP_VERSION
PRODUCT
VERSION
BUILD_ID
BUILD_TARGET
OS_VERSION
LOCALE
CHANNEL
PLATFORM_VERSION
DISTRIBUTION
DISTRIBUTION_VERSION
PING_COUNT
TOTAL_PING_COUNT
DAYS_SINCE_LAST_PING

The TOTAL_PING_COUNT (stored in extensions.blocklist.pingCountTotal) is also interesting. Because this number increments every time you start the Tor browser. (note: once a day). As you can see the number in the URL above is 34, what means that the Tor browser was started at least 34 times/days.

Technical info:

source code: XMLHttpRequest with BadCertHandler

source code: BadCertHandler:

/**
 * This class implements nsIBadCertListener.  Its job is to prevent "bad cert"
 * security dialogs from being shown to the user.  It is better to simply fail       
 * if the certificate is bad. See bug 304286.          <--   :-|
 */

Another URL with sensitive data is extensions.update.background.url:

https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%

Related Bugzilla tickets:

Child Tickets

Change History (8)

comment:1 Changed 2 years ago by yawning

Cc: yawning added

comment:2 Changed 2 years ago by yawning

Sigh. Per Mozilla's documentation this should not be happening, though at this point I have no reason to doubt that it is.

https://www.mozilla.org/en-US/privacy/firefox/

Add-ons Blocklist: Firefox contacts Mozilla once per day to check for add-on information to check for malicious add-ons. This includes, for example: browser version, OS and version, locale, total number of requests, time of last request, time of day, IP address, and the list of add-ons you have installed. You can turn off metadata updates at any time, but it may leave you open to security vulnerabilities.

https://blog.mozilla.org/addons/how-to-opt-out-of-add-on-metadata-updates/

  1. In the Filter text box, type extensions.getAddons.cache.enabled.
  2. Double click the extensions.getAddons.cache.enabled item to turn it from true to false

That pref is disabled by default in Tor Browser.

comment:3 in reply to:  2 ; Changed 2 years ago by basvd

Replying to yawning:

  1. In the Filter text box, type extensions.getAddons.cache.enabled.
  2. Double click the extensions.getAddons.cache.enabled item to turn it from true to false

That pref is disabled by default in Tor Browser.

Blocklist is using this one: extensions.blocklist.enabled (..and that's default true)

comment:4 in reply to:  3 Changed 2 years ago by yawning

Replying to basvd:

Blocklist is using this one: extensions.blocklist.enabled (..and that's default true)

So their "Privacy Notice" is full of shit and links to incomplete opt out documentation. Like I said, I don't doubt that this happens.

comment:5 Changed 2 years ago by tom

It's intentional that certificate errors are ignored. We have to deal with tls-intercepting and messed up middleboxes. Updates are the same way. Blocklists should be signed, and edited blocklists (such as with Burp) should not be accepted. If you can find a way to bypass that, please file a Mozilla security bug and collect a nice bounty.

Replying to yawning:

Replying to basvd:

Blocklist is using this one: extensions.blocklist.enabled (..and that's default true)

So their "Privacy Notice" is full of shit and links to incomplete opt out documentation. Like I said, I don't doubt that this happens.

Describing it as 'full of shit' seems inaccurate to me. It links to incorrect documentation and thus is misleading people about actually opting out, but it clearly describes that it collects technical information that can be used to identify people.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1382006 to address the incorrect information.

I am confused why the add-on blocklist is (attempted) to be disabled via the old pref. Extension blocklisting and updating (and that it is enabled in Tor Browser) is discussed in detail in #21200 and is actually targeted as the first onion service Mozilla deploys. That is behind schedule but nonetheless - the fact that it's used in Tor Browser was (I thought) well established.

The certificate thing is a misunderstanding. Breaking TLS sounds bad, but shouldn't matter in practice.

That Mozilla could block Tor Extensions (like Tor Launcher) also sounds bad, but also in practice doesn't matter - when this is done the browser stops working but does not bypass the (no-longer-present) proxy. If Tor wanted to turn off blocklist updating nonetheless, I'd say that's reasonable since we discourage users from installing custom extensions and in general don't support that use case.

If you can find a way for Mozilla to force install extensions, flip prefs, or update extensions outside of the extension developer's control[0] - that would be a very concerning bug.

Mozilla *can* revoke CAs unilaterally without Tor's control via OneCRL.

[0] I know HTTPS Everywhere uses a separate additional signing key that Mozilla doesn't control that should prevent Mozilla from pushing updates. I actually haven't checked NoScript but I hope it does the same?

comment:6 in reply to:  5 Changed 2 years ago by yawning

Replying to tom:

So their "Privacy Notice" is full of shit and links to incomplete opt out documentation. Like I said, I don't doubt that this happens.

Describing it as 'full of shit' seems inaccurate to me. It links to incorrect documentation and thus is misleading people about actually opting out, but it clearly describes that it collects technical information that can be used to identify people.

The opt out instructions don't work.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1382006 to address the incorrect information.

Thank you.

I am confused why the add-on blocklist is (attempted) to be disabled via the old pref. Extension blocklisting and updating (and that it is enabled in Tor Browser) is discussed in detail in #21200 and is actually targeted as the first onion service Mozilla deploys. That is behind schedule but nonetheless - the fact that it's used in Tor Browser was (I thought) well established.

It might even make it to production before a Tor Browser release that disables the "Get Addons" pane (#22073).

That Mozilla could block Tor Extensions (like Tor Launcher) also sounds bad, but also in practice doesn't matter - when this is done the browser stops working but does not bypass the (no-longer-present) proxy. If Tor wanted to turn off blocklist updating nonetheless, I'd say that's reasonable since we discourage users from installing custom extensions and in general don't support that use case.

I just pushed a commit to the sandboxed version that forces it off, because the container setup explicitly only exposes standard extensions within the container.

[0] I know HTTPS Everywhere uses a separate additional signing key that Mozilla doesn't control that should prevent Mozilla from pushing updates. I actually haven't checked NoScript but I hope it does the same?

The XPI says "yeah right" (Keys/signatures omitted for brevity).

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1496120746499 (0x15c57bee203)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Mozilla Corporation, OU=Mozilla AMO Production Signing Service, CN=production-signing-ca.addons.mozilla.org/emailAddress=services-ops+addonsigning@mozilla.com
        Validity
            Not Before: May 30 05:05:46 2017 GMT
            Not After : May 29 05:05:46 2022 GMT
        Subject: OU=Production, C=US, L=Mountain View, O=Addons, ST=CA, CN={73a6fe31-595d-460b-a920-fcc0f8843232}

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1048578 (0x100002)
    Signature Algorithm: sha384WithRSAEncryption
        Issuer: C=US, O=Mozilla Corporation, OU=Mozilla AMO Production Signing Service, CN=root-ca-production-amo
        Validity
            Not Before: Mar 17 23:52:42 2015 GMT
            Not After : Mar 14 23:52:42 2025 GMT
        Subject: C=US, O=Mozilla Corporation, OU=Mozilla AMO Production Signing Service, CN=production-signing-ca.addons.mozilla.org/emailAddress=services-ops+addonsigning@mozilla.com

comment:7 Changed 2 years ago by cypherpunks

Last edited 2 years ago by cypherpunks (previous) (diff)

comment:8 Changed 2 years ago by gk

Resolution: duplicate
Status: newclosed

So, reading through all the comments it seems 2) is the remaining issue in this bug? If so, then we have #16931 for this problem. Marking this as a duplicate.

Note: See TracTickets for help on using tickets.