Opened 3 years ago

Last modified 12 months ago

#20146 needs_review defect

Firefox bug - (CVE-2016-5284) ESR-45/Tor Browser certificate pinning bypass for addons.mozilla.org and other built-in sites

Reported by: mancha Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security, tls
Cc: brade, mcs, gk, boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

A. SHORT BACKGROUND

As originally reported by @movrcx and subsequently analyzed by Ryan Duff, Mozilla Firefox ESR 45 (upon which Tor Browser 6.0.4 is built) does not currently honor its static certificate pinning.

In theory, TLS connections to Mozilla AUS and AMO servers (e.g. [*.]addons.mozilla.org, aus4.mozilla.org, aus5.mozilla.org) and other built-in sites are validated by ensuring:

  1. a chain can be constructed from the server-provided certificate to a trusted root certificate; and
  2. the constructed trusted certificate chain matches the pinset (either dynamically provided via HPKP Public-Key-Pins headers or hard-coded in static lists).

In particular, Mozilla's AUS and AMO servers don't currently emit HPKP headers so they're checked against built-in static pins.

B. PROBLEM

Here's the rub:

  • Firefox static pins have a 90-day lifetime after which they're no longer binding
  • Mozilla's automated static pin expiry extension process appears to be broken

As a result ESR 45.3 static pins expired on September 3, 2016.

Whoa! What does this all mean?

In short, since September 3, 2016, anyone using ESR 45.3/TBB 6.0.4 (or earlier) is vulnerable to MiTM attacks from adversaries in possession of certificates that properly validate through to Firefox's trusted root store (no pinning enforced). In other words, of the two conditions mentioned above, only the first needs to be met.

Such an adversary could, in theory, have an [*.]addons.mozilla.org certificate and use it to deliver malicious payloads via crafted add-on updates (e.g. NoScript).

Note: It should be mentioned that though the second condition is not being enforced, the first condition is not trivially met. However, it's hurdle that's certainly within the reach of sophisticated adversaries such as state-level actors.

C. RECOMMENDATION

Mozilla's decision to cap static pin lifetimes at 90 days is to prevent sites from blacklisting themselves (balancing security and usability). Tor Browser, on the other hand, is security infrastructure above all else.

For this reason, it is recommended the Tor Browser do away with expiration checks altogether (see patch below). This will ensure built-in static pins are always honored and not bypassed.

Tor Browser users who update regularly (a practice that should be encouraged independently of this issue) should never find themselves with stale pinsets anyways.

--- a/security/manager/ssl/PublicKeyPinningService.cpp
+++ b/security/manager/ssl/PublicKeyPinningService.cpp
@@ -254,10 +254,6 @@ FindPinningInformation(const char* hostn
   }

   if (foundEntry && foundEntry->pinset) {
-    if (time > TimeFromEpochInSeconds(kPreloadPKPinsExpirationTime /
-                                      PR_USEC_PER_SEC)) {
-      return NS_OK;
-    }
     staticFingerprints = foundEntry;
   }
   return NS_OK;

D. OTHER

It is further recommended the Tor Browser team review the Firefox update process to ensure it is consistent with Tor's increased security requirements.

Child Tickets

Change History (15)

comment:1 Changed 3 years ago by mcs

Cc: brade mcs added

I think it is worthwhile to think about doing this. But never expiring the static pins will make updates fail for users of an old Tor Browser when the certificates associated with the torproject.org servers are ever changed. It would be worthwhile to look at what the failure mode is, and maybe make improvements.

We should also see what solution Mozilla comes up with for this problem.

comment:2 Changed 3 years ago by arma

I've heard a variety of proposed ideas for how to make things better. In an attempt to organize my thoughts, here they are:

Option 1: make pinning never expire (i.e. do this ticket). The upside is that old Tor Browser users never have to worry about becoming surprisingly vulnerable. The downside is that we can't ever change our CA, or people with old browsers will be pinned to the wrong CA and will fail to do updates. That seems like a pretty big downside, since one day our CA is going to have problems and we'll want to switch.

Option 2: Disable noscript updates between releases. That is, put a version of Noscript into Tor Browser when we build Tor Browser, and then people stick with that version until the next Tor Browser. (If I understand correctly, the only two extensions in Tor Browser that want to update themselves are noscript and https-everywhere, and https-everywhere uses the updateKey signature mechanism to check its own updates, so we are not as worried about it.) The upside of this option is that Tor Browser users are no longer vulnerable to today's attack, and in fact they are no longer vulnerable to malicious updates by a *real* addons.m.o. That's a pretty big upside. The downside is that the Tor Browser folks would need to track noscript updates for security issues, and put out a new Tor Browser release as needed. That could potentially be a lot more releases.

Option 3: Convince the noscript maintainer to adopt the updateKey signature mechanism. Then nobody is at the mercy of addons.m.o (not the key pinning issue and not the malicious updates issue). But I hear that apparently updateKey isn't compatible with addons.m.o -- meaning if you use addons.m.o then you are forced to rely on their transport security for your updates. So for this option I guess we encourage the noscript maintainer to both adopt the updateKey signature mechanism, *and* put updates somewhere else where signatures can work.

Other more muddy options include "wait and see if Mozilla fixes some of their broken designs in a way that is helpful here".

comment:3 Changed 3 years ago by arma

Sebastian points out, I think correctly, that right now there is an https-everywhere update key somewhere in the world that is trusted by Tor Browser users (i.e. it can give them a bad update if it wants). GeKo points out that this issue is #10394.

Separately, there is a site called addons.m.o which is trusted by Tor Browser users, because it can give them a bad noscript (either by having users accidentally go to a fake addons.m.o, or by having users go to the real one and it gives them a bad update).

My 'option 1' above leaves both of these issues in place.

My 'option 2' resolves both of them, assuming we do it for both noscript and https-everywhere.

Whereas my 'option 3' replaces the addons.m.o issue with a new "there's a noscript update key somewhere in the world that is trusted" issue.

This logic makes me like 'option 2' even more.

comment:4 in reply to:  3 Changed 3 years ago by gk

Cc: gk added

Replying to arma:

This logic makes me like 'option 2' even more.

Yes, if we can afford it release-wise that sounds like a good way forward to deal with the extensions issue. I am not sure what we want to do with the hotfix updates, though. I guess studying that a bit more (what got fixed in the past etc.) could help making a decision.

comment:5 Changed 3 years ago by boklm

Cc: boklm added

Mozilla is discussing increasing the lifetime of pinning:
https://bugzilla.mozilla.org/show_bug.cgi?id=1303414

comment:6 Changed 3 years ago by flyryan

Hey everyone. Just wanted to throw Mozilla's statement in here. They are enabling HPKP to addons.mozilla.org which will inherently fix the problem. They could do this right now and fix all of Firefox but I don't know if that's their plan or if they are waiting until Tuesday.

We investigated this and a fix will be issued in the next Firefox release on Tuesday, September 20. We had fixed an issue with the broken automation on the Developer Edition on September 4, but a certificate pinning had expired for users of our Release and Extended Support Release versions. We will be turning on HPKP on the addons.mozilla.org server itself so that users will remain protected once they have visited the site even if the built-in pins expire. We will be changing our internal processes so built-in certificate pins do not expire prematurely in future releases.

Last edited 3 years ago by flyryan (previous) (diff)

comment:7 in reply to:  2 Changed 3 years ago by cypherpunks

Replying to arma:

I've heard a variety of proposed ideas for how to make things better. In an attempt to organize my thoughts, here they are:

Option 1: make pinning never expire (i.e. do this ticket).


Option 2: Disable noscript updates between releases. That is, put a version of Noscript into Tor Browser when we build Tor Browser


Option 3: Convince the noscript maintainer to adopt the updateKey signature mechanism.

You might also consider a hybrid of 2 and 3: ship a version that only trusts Tor's keys—the same ones checked when updating the browser itself—and set up an onion service it can poll for updates.

I think its worthwhile to decrease the number of trust roots. Even if you weren't doing much more than re-signing each release, you'd be able to stop distributing a compromised update when someone noticed it. And you'd keep a history of everything you've signed, so nothing could slip through without a record.

comment:8 Changed 3 years ago by jmprcx

Greetings folks,

Just wanted to add some input here and much respect to all for fixing this problem.

The Mozilla-proposed solution is garbage to my understanding. If HPKP is used I believe they get wiped in private browsing mode so then it offers no protection on the next startup when the static pins are expired. HPKP can also be used as a method to track user activity so some users may not want to store pins.

I like option 2 as proposed. Also maybe it would be worthwhile to do updates over onion service only? I don't see a point in making a Tor Browser user beacon out to the clearnet for no good reason.

-jmprcx

Last edited 3 years ago by jmprcx (previous) (diff)

comment:9 Changed 3 years ago by tscpd

further advantage of armas option2: TB fingerprint is less unique

further advantage of setting up a onionservice for it: it will reduce load of exitrelays

Last edited 3 years ago by tscpd (previous) (diff)

comment:10 Changed 3 years ago by cypherpunks

Also consider disabling extension auto updates by default and only enable it if/where needed, e.g. noscript and https-everywhere. This would prevent leaking which custom extensions are installed

comment:11 Changed 3 years ago by mancha

Keywords: CVE-2016-5284 added

comment:12 Changed 3 years ago by bugzilla

Keywords: tbb-security added; CVE-2016-5284 removed
Status: newneeds_review
Summary: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sitesFirefox bug - (CVE-2016-5284) ESR-45/Tor Browser certificate pinning bypass for addons.mozilla.org and other built-in sites

Where does the actual security discussion take place?

As OP provides a patch, it's not polite to leave this ticket as new.

@TBB Team, for the record:
It wasn't

irresponsible disclosure

because
https://twitter.com/EisMC2/status/775440744202981376

@dexterdyne @movrcx @torproject nah they actively have ignored serious 0 days before, submit by good people who know wth theyre talkin about

https://twitter.com/movrcx/status/776800848752078848

@jrmithdobbs @matthew_d_green @torproject @ioerror No.I attempted responsible disclosure and was ridiculed. So I dropped public Full Disclsr

comment:13 Changed 2 years ago by cypherpunks

What is the state of this bug? It was opened half a year ago and remains immediate/critical severity level. Has it been mitigated in any other ways so far?

comment:14 in reply to:  13 Changed 2 years ago by gk

Priority: ImmediateMedium
Severity: CriticalNormal

Replying to cypherpunks:

What is the state of this bug? It was opened half a year ago and remains immediate/critical severity level. Has it been mitigated in any other ways so far?

Yes, the bypass has stopped with updating the pinning lifetime/releasing new Tor Browser versions. Thus, we can downgrade the severity. We can probably close this bug but I have to think first how to move the action items/ideas in this one into other/new bugs.

comment:15 Changed 12 months ago by traumschule

Keywords: tls added
Note: See TracTickets for help on using tickets.