Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #20146

Closed (moved)
Open
Opened Sep 16, 2016 by Trac@tracbot

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

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.

Trac:
Username: mancha

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#20146