811928 - The patch for bug 753116 seems to cause NSS_NoDB_Init to fail occasionally

Status: RESOLVED DUPLICATE of bug 812399

(NSS :: Libraries, defect, P1)

Description

[Wan-Teh Chang]

The patch for bug 753116 (softoken needs to split out common components to util)
seems to cause NSS_NoDB_Init to fail in Chromium.

This is the crash that Ryan Sleevi mentioned before NSS 3.14 was released.
Due to a mistake of mine, I thought the crash was pre-existing. Later we
determined the crash was caused by NSS 3.14.

Here is the call sequence in Chromium:

1. NSS_NoDB_Init() is called from a one-time initialization function similar
to PR_CallOnce. Unfortunately this one-time initialization function returns
void, so we don't yet have direct evidence that NSS_NoDB_Init() failed.

2. SECKEY_ExtractPublicKey() is called.

For a small number of users, Chromium crashes inside SECKEY_ExtractPublicKey()
with this call stack:

Thread 9 *CRASHED* ( EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE @ 0x0000000c )

0x3bf97262	 [Google Chrome Framework]	 - plhash.c:381]	PL_HashTableLookupConst
0x3c04d673	 [Google Chrome Framework]	 - secoid.c:1995]	SECOID_FindOID_Util
0x3c04d330	 [Google Chrome Framework]	 - secoid.c:2011]	SECOID_FindOIDTag_Util
0x3bfae099	 [Google Chrome Framework]	 - seckey.c:576]	seckey_ExtractPublicKey
0x3beee440	 [Google Chrome Framework]	 - signature_verifier_nss.cc:40]	crypto::SignatureVerifier::VerifyInit

signature_verifier_nss.cc:40 is:

  SECKEYPublicKey* public_key = SECKEY_ExtractPublicKey(spki);

The relevant code in secoid.c is:

1988 SECOidData *
1989 SECOID_FindOID(const SECItem *oid)
1990 {
1991     SECOidData *ret;
1992 
1993     PR_ASSERT(oidhash != NULL);
1994      
1995     ret = PL_HashTableLookupConst ( oidhash, oid );
1996     if ( ret == NULL ) {
1997         ret  = secoid_FindDynamic(oid);
1998         if (ret == NULL) {
1999             PORT_SetError(SEC_ERROR_UNRECOGNIZED_OID);
2000         }
2001     }
2002 
2003     return(ret);
2004 }

The bad access at address 0x0000000c in PL_HashTableLookupConst
implies oidhash is NULL. Since we called NSS_NoDB_Init beforehand,
a good explanation for the null oidhash is that NSS initialization
failed.

I have narrowed down the NSS patch that introduced this crash.
It is the patch for bug 753116. I created a Chromium changelist
from that patch, including the crash fix that  Ted Mielczarek
submitted for bug 785208: https://codereview.chromium.org/11362174

Since Chromium patches NSS to use it as static libraries, it is
possible that this crash is caused by Chromium's static linking
patches. But I think it is extremely unlikely, because the NSS
trunk snapshot right before the patch for bug 753116 does not
cause this crash.

Unfortunately the patch for bug 753116 is quite large. I already
inspected it once before and didn't spot any problem.

Comment 1

[Robert Relyea]

Check the use of SECOID_Init().

Static linking could indeed cause situations where SECOID_Init() is not properly called in your application. We had similiar issues when separating out util and softoken.

bob

Comment 2

[Ryan Sleevi]

Bob - it is not clear to me what you were asking about in your comment.

SECOID_Init should be called during NSS Init (nss_Init, specifically - http://mxr.mozilla.org/security/source/security/nss/lib/nss/nssinit.c#656 )

I agree, it does seem to indicate that SECOID_Init() may be failing to be called, which should only happen if NSS initialization failed (!isReallyInited)

This seems to indicate that on some systems, NSS itself is failing to be initialized. Wan-Teh has added code to try to understand if this is the case.

Comment 3

[Wan-Teh Chang]

Bob: I added code to Chromium to force it to crash with error code
info if NSS_NoDB_Init failed. I just got a crash report with error
code SEC_ERROR_LEGACY_DATABASE (-8015). NSS 3.14 sets this error in
only two places:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/util/utilmod.c&rev=1.7&mark=344,355-356,358#344

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/util/utilmod.c&rev=1.7&mark=648-649,651#634

I will add more debugging code to narrow down to the exact place.

Another piece of info: Chromium does not ship with the libnssdbm3 library.

Comment 4

[Wan-Teh Chang]

The latest Chrome crash reports showed the SEC_ERROR_LEGACY_DATABASE
error is set here:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/util/utilmod.c&rev=1.7&mark=344,355-356,358#344

So the affected users have /secmod.db (but don't have /pkcs11.txt) on
their computers (usually Macs), but Chrome doesn't ship libnssdbm3, so
NSS_NoDB_Init fails.

This confirms this bug is a duplicate of bug 812399.