#20146: Tor browser certificate pinning bypass for addons.mozilla.org and other
pinned sites
     Reporter:  mancha                    |      Owner:  tbb-team
         Type:  defect                    |     Status:  new
     Priority:  Immediate                 |  Milestone:
    Component:  Applications/Tor Browser  |    Version:
     Severity:  Critical                  |   Keywords:
Actual Points:                            |  Parent ID:
       Points:                            |   Reviewer:
      Sponsor:                            |

 As originally reported by
 [https://twitter.com/movrcx/status/775817737574633472 @movrcx] and
 subsequently analyzed by [http://seclists.org/dailydave/2016/q3/51 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[[BR]]
  1. 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
 [https://bugzilla.mozilla.org/show_bug.cgi?id=1303127 appears to be

 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.


 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

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20146>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
tor-bugs mailing list

Reply via email to