1342309 - if the NSS crypto policy has a higher minimum tls version than the user's prefs (or the defaults), Firefox crashes just after startup [ @ nsNSSComponent::nsNSSComponent() ]

Status: RESOLVED DUPLICATE of bug 1328318

(Core :: Security: PSM, defect, P3)

Description

[Daniel Brooks [:db48x]]

Attachment: longer stacktrace

I'm not entirely sure what's triggered this; I last upgraded a week or so ago, and it only just started crashing. This is Firefox 51.0.1.

The crash reporter doesn't have symbols for this Fedora build, but I captured it in gdb:

    0x00007fffe96d1f86 in nsNSSComponent::nsNSSComponent (this=<optimized out>) at /usr/src/debug/firefox-51.0.1/firefox-51.0.1/security/manager/ssl/nsNSSComponent.cpp:259
    259       MOZ_RELEASE_ASSERT(NS_IsMainThread());

See https://crash-stats.mozilla.com/report/index/83bdbbd3-5d0a-4a6d-a25d-f9bb82170224, and also the longer stack trace that I've attached.

Comment 1

[Daniel Brooks [:db48x]]

It just occurred to me that Fedora would use a system NSS, so I double checked. The crash is in libxul:

0x00007fffe7d84310  0x00007fffea270460  Yes         /usr/lib64/firefox/libxul.so

so it doesn't seem like mismatched versions.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Couple of things to try:
* `thread apply all bt` in gdb to get a backtrace for all threads
* can you reproduce in a new profile?
* can you reproduce using the original profile but using an official build of Firefox? (i.e. not the Fedora repackaged version)
* what add-ons do you have installed?
* do you have any pkcs#11 modules?

Comment 3

[Daniel Brooks [:db48x]]

(In reply to Dana Keeler [:keeler] (use needinfo?) from comment #2)
> Couple of things to try:
> * `thread apply all bt` in gdb to get a backtrace for all threads

Sure. All but two threads are waiting or polling. I'll attach a stack trace of the other one; it's doing some storage stuff which is creating a new thread.

> * can you reproduce in a new profile?

Yes.

> * can you reproduce using the original profile but using an official build
> of Firefox? (i.e. not the Fedora repackaged version)

Ah, official builds work fine

> * what add-ons do you have installed?

A fair few.

> * do you have any pkcs#11 modules?

Nope.

Comment 4

[Daniel Brooks [:db48x]]

Attachment: stacktrace for thread 1

Comment 5

[Daniel Brooks [:db48x]]

Attachment: javascript stack from thread 1

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Hmmm - how about running with the environment variable "MOZ_LOG=pipnss:5"? That should hopefully give some logging output. Also, do you happen to know what add-ons are bundled with Fedora's build of Firefox?

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler]]

(in case you didn't see comment 6)

Comment 8

[Daniel Brooks [:db48x]]

Attachment: MOZ_LOG=pipnss:5

It doesn't appear to say why it failed though, just that it did.

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler]]

If you have the time, maybe break on nsNSSComponent::InitializeNSS in gdb and `next` through until something fails?

Comment 10

[Daniel Brooks [:db48x]]

GetNSSProfilePath fails, though the optimized code jumped around too much inside it for me to follow for sure, but it looked like it got the nsIFile for the profile directory, then calling GetNativePath failed.

Comment 11

[Daniel Brooks [:db48x]]

That doesn't make much sense though, so I probably misread it.

Comment 12

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Hmmm - that is a bit strange, since if GetNSSProfilePath fails, the line that prints "inSafeMode: 0" shouldn't run.
The only places I can see in that function that would return a failing error code without printing anything else are setEnabledTLSVersions, SSL_ConfigServerSessionIDCache, and getting the nsICertBlocklist service. Can you see if it's failing at any of those?

Comment 13

[Daniel Brooks [:db48x]]

I don't see a call to SSL_ConfigServerSessionIDCache; what line is it on? The other two don't fail.

Comment 14

[Dana Keeler (she/her) (use needinfo) [:keeler]]

I'm working off of https://dxr.mozilla.org/mozilla-release/rev/1f0fc9316e65cd171b03d4382b4c0f7443a258dc/security/manager/ssl/nsNSSComponent.cpp#1800 which I think should be Firefox 51. But then again, Fedora may have made modifications.

Comment 15

[Daniel Brooks [:db48x]]

I take it back; I think setEnabledTLSVersions is failing. When I step into it, srv is SECFailure. Confusingly, it then steps to return NS_OK. I also can't step into SSL_VersionRangeSetDefault, though I can break on the functions it calls. It looks like ssl_VersionIsSupportedByPolicy is returning false.

Comment 16

[Daniel Brooks [:db48x]]

Aha! I just "fixed" it. A day or two ago I tweaked the default crypto policy from DEFAULT to FUTURE, primarily to update my sshd_config. It does make some other changes though:

     db48x  /  usr  share  crypto-policies  cat DEFAULT/nss.txt
    library=
    name=Policy
    NSS=flags=policyOnly,moduleDB
    config="disallow=ALL allow=HMAC-SHA1:HMAC-SHA256:HMAC-SHA384:HMAC-SHA512:SECP256R1:SECP384R1:SECP521R1:aes256-gcm:chacha20-poly1305:aes256-cbc:camellia256-cbc:aes128-gcm:aes128-cbc:camellia128-cbc:des-ede3-cbc:SHA256:SHA384:SHA512:SHA1:ECDHE-RSA:ECDHE-ECDSA:RSA:DHE-RSA:DHE-DSS:tls-version-min=tls1.0:dtls-version-min=dtls1.0:DH-MIN=1023:DSA-MIN=1023:RSA-MIN=1023"


     db48x  /  usr  share  crypto-policies  cat FUTURE/nss.txt
    library=
    name=Policy
    NSS=flags=policyOnly,moduleDB
    config="disallow=ALL allow=HMAC-SHA1:HMAC-SHA256:HMAC-SHA384:HMAC-SHA512:SECP256R1:SECP384R1:SECP521R1:aes256-gcm:chacha20-poly1305:aes256-cbc:camellia256-cbc:aes128-gcm:aes128-cbc:camellia128-cbc:SHA256:SHA384:SHA512:ECDHE-RSA:ECDHE-ECDSA:RSA:DHE-RSA:DHE-DSS:tls-version-min=tls1.2:dtls-version-min=dtls1.2:DH-MIN=2048:DSA-MIN=2048:RSA-MIN=2048"
 db48x  /  usr  share  crypto-policies  

You can see that it sets a higher minimum TLS version. When I move back to the DEFAULT version of nss.txt, it doesn't crash on startup any more. If I have it using the FUTURE policy, and I set the security.tls.version.min pref to 3 then it also doesn't crash.

Seems to me the fix would be to bump the minimum version to the minimum set by the policy, instead of letting it crash the whole browser.

Comment 17

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Ah, that makes sense. Thanks for tracking that down!

Comment 18

[Daniel Brooks [:db48x]]

You're welcome; it was a pretty fun exercise overall.

Comment 19

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 21

[Dana Keeler (she/her) (use needinfo) [:keeler]]

I believe bug 1328318 made it so NSS will adjust the passed-in range depending on if any policy is set, so as long as those ranges are both valid in and of themselves, the call won't fail and NSS will be initialized successfully.