New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 707280 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

HPKP bypass because all roots are considered local on Fedora

Reported by dkee...@mozilla.com, Mar 31 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Steps to reproduce the problem:
1. install Fedora
2. visit https://pinning-test.badssl.com/
3. :(

What is the expected behavior?
This page should be blocked because it fails pinning checks.

What went wrong?
It seems that the determination of whether or not a root certificate is a built-in system root or a user-imported root isn't robust against things Fedora does. Firefox has had similar issues in the past:

https://bugzilla.mozilla.org/show_bug.cgi?id=1272858
https://bugzilla.mozilla.org/show_bug.cgi?id=1324096
https://bugzilla.redhat.com/show_bug.cgi?id=1207335

Did this work before? N/A 

Chrome version: 57.0.2987.110 (Official Build) (64-bit)  Channel: stable
OS Version: Fedora/25
Flash Version:
 
Components: Internals>Network>DomainSecurityPolicy
Summary: HPKP bypass because all roots are considered local on Fedora (was: public-key pinning bypass because all roots are considered local on Fedora)

Comment 2 by ta...@google.com, Apr 1 2017

Labels: Security_Impact-Stable Security_Severity-High
Owner: lgar...@chromium.org
Status: Assigned (was: Unconfirmed)
lgarron@, I wonder if you are the right person to investigate this.
Project Member

Comment 3 by sheriffbot@chromium.org, Apr 1 2017

Labels: M-57
Project Member

Comment 4 by sheriffbot@chromium.org, Apr 1 2017

Labels: -Pri-2 Pri-1
Cc: rsleevi@chromium.org
 Issue 708336  has been merged into this issue.
I don't think we need to consider this a Security bug. Because roots are considered local, pinning is never set in the first place, therefore it's not a degradation of security.

Assuming we will open this bug, I'll refrain from sharing my personal views regarding what Fedora does. I will note that there are some other technical alternatives only in the most recent versions of NSS, but we've not yet been able to uprev the minimum Linux NSS version ( Issue 691261 ), although we'd have to depend on a much newer version to take advantage of them.

I think migrating off NSS may be the more expedient path, and do not think the failure to allow setting HPKP (given its significant risks) should be a Security bug at all.
I don't think we need to consider this a Security bug. Because roots are considered local, pinning is never set in the first place, therefore it's not a degradation of security.

Assuming we will open this bug, I'll refrain from sharing my personal views regarding what Fedora does. I will note that there are some other technical alternatives only in the most recent versions of NSS, but we've not yet been able to uprev the minimum Linux NSS version ( Issue 691261 ), although we'd have to depend on a much newer version to take advantage of them.

I think migrating off NSS may be the more expedient path, and do not think the failure to allow setting HPKP (given its significant risks) should be a Security bug at all.
In retrospect "HPKP" was the wrong word to use in the summary - if I'm understanding correctly, even preloaded pins aren't enforced, which seems problematic.
We intentionally don't enforce preloaded pins on a variety of platforms, so it's not a strict security issue in my mind.
Ah, ok then. Your analysis makes sense.
Cc: lgar...@chromium.org
Owner: ----
Status: Available (was: Assigned)
I don't think I can make a useful decision here.

How are Chromium builds for Fedora built and distributed?
If it's not an official Google build, Chromium should compile without preloaded HPKP unless the distributor takes responsibility to enable it carefully.
@lgarron: This is not about Chromium builds for Fedora. It would also apply to Google Chrome builds run on Fedora.
*Do* we have Google Chrome builds for Fedora?
I think I agree with rsleevi that this is not a Chrome security bug. It might be a Fedora security bug, though.
@Comment 15: Why do you say Fedora? What they're doing is perfectly legal (and supported by NSS developers, which I suspect is why David mentioned it)

There's a new trust attribute added in newer versions of NSS that indicate built-in or not, with the assumption that those not built-in will not set it, but the Linux dependency hell is why I suggested it's not a reliable signal.
If we ship an official build on Fedora, isn't it a bug that HPKP is useless?

If we don't consider it ours to fix, is ExternalDependency appropriate?
lgarron: I'm trying to separate out two things:

Whether it's a bug (it is) from whether it's a security bug (that's questionable).

It's currently marked Sec_Severity-High. I'm not sure how that's consistent with our lack of shipping static HPKP pinning on platforms that don't support updates (Android, iOS) and the HPKP bypasses when Microsoft's AUTHROOT updates (Windows). In my mind, Static-HPKP was "Best effort, where we can", given those statements.

I'm not opposed to treating it as a bug, and as much as I'd love to drive  Issue 691261  to hopefully make this easier to solve, that's not a priority. But I'm questioning the triage.
Labels: -Security_Severity-High Security_Severity-Low
It sounds like there is a rough consensus emerging that this is not a high severity Chrome security bug, and may not be a security bug in Chrome at all. I'll drop the severity for now.

Looking at Firefox's behaviour here might be instructive. For example, could we implement the workaround in https://bugzilla.mozilla.org/show_bug.cgi?id=1324096 ?

@Comment 19: Oh, we know the solution. The problem is we can't depend on it with our current NSS dependencies. See Comment 7.

Mozilla ships a hermetic copy of NSS. For various reasons, we opted not to do this.
Labels: -Type-Bug-Security -Pri-1 -Restrict-View-SecurityTeam -Security_Severity-Low -Security_Impact-Stable -Via-Wizard-Security Pri-2 Type-Bug
Thanks for the feedback. Taking the security restrictions off this one.
Project Member

Comment 22 by bugdroid1@chromium.org, Dec 28 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b7b0457e35ca5fa1ca4df84c493767d73cae3690

commit b7b0457e35ca5fa1ca4df84c493767d73cae3690
Author: Ryan Sleevi <rsleevi@chromium.org>
Date: Thu Dec 28 21:11:12 2017

Use PK11_HasAttributeSet on Linux to determine root status when available

NSS 3.30 introduced PK11_HasAttributeSet(), along with
CKA_NSS_MOZILLA_CA_POLICY, to determine whether or not a certificate is
part of the "built-in" set. This was introduced because some
distributions replace NSS's nssckbi.so with a redirect to a
distro-specific version which does not maintain the same properties as
the upstream Mozilla version.

Generally, this is a redirect to p11-kit, to allow multiple trust sources
(upstream, per-system, admin-defined, user-defined) to be integrated as if
they're a single store. Unfortunately, this breaks the detection logic
for whether or not a certificate is issued by a known root on Linux.

As Chromium does not yet require an NSS version >= 3.30, use dlsym to
detect the function, and if it's available, do the more expensive query
to determine whether or not a cert is a known-root, while keeping the
fallback to the existing path.

BUG= 707280 

Change-Id: I340dafe56e605515d2421c33cf1b05f9431f6126
Reviewed-on: https://chromium-review.googlesource.com/845095
Reviewed-by: Eric Roman <eroman@chromium.org>
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526325}
[modify] https://crrev.com/b7b0457e35ca5fa1ca4df84c493767d73cae3690/net/cert/known_roots_nss.cc

Labels: -M-57 M-65
Status: Fixed (was: Available)
On a Fedora system with an NSS version >= 3.30, the site https://pinning-test.badssl.com/ should fail to load

On a Fedora system with an NSS version < 3.30, the site https://pinning-test.badssl.com/ should load (due to it being treated as a local anchor)

This doesn't change the runtime dependencies for Chrom[e/ium] on such systems to require >= 3.30, hence the need to determine which version of nss. https://apps.fedoraproject.org/packages/nss indicates that Rawhide, 27, and 26 should all be shipping 3.34

Sign in to add a comment