Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:  CVE-2016-5284 |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mancha):

 * keywords:   => CVE-2016-5284


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (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
 if exitrelays

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (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 pins
 are used I believe they get wiped in private browsing mode so then it
 offers no protection on the next startup. HPKP pins 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 add-
 ons 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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:2 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by flyryan):

 Hey guys. 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * cc: boklm (added)


Comment:

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: gk (added)


Comment:

 Replying to [comment:3 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (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".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#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:|
--+--
 '''A. SHORT BACKGROUND'''

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs