Closed Bug 1126027 Opened 9 years ago Closed 8 years ago

Segfault at nsNSSCertificateDB::SetCertTrust() after changing trust settings of an e-mail cert in the cert manager

Categories

(Core :: Security: PSM, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1168048

People

(Reporter: Cykesiopka, Unassigned)

Details

(Keywords: sec-low)

Attachments

(2 files)

728 bytes, application/x-x509-ca-cert
Details
707 bytes, application/x-x509-ca-cert
Details
STR:
 - Go to the "Authorities" tab of the Cert Manager and import the CA cert I will attach to the bug
   - Trust for e-mail
 - Go to the "People" tab and import the e-mail cert
 - Trust the e-mail cert via the "Edit Trust..." dialogue
 - Press OK to dismiss the Cert Manager, then reopen it
 - Find the e-mail cert that should now be under the "Servers" tab and "Delete..." it
 - Press OK to dismiss the Cert Manager, then reopen it
 - Go to the "People" tab, select the e-mail cert, and open and close the "Edit Trust..." dialogue until the top section that is usually filled with text is empty
   - This shouldn't take more than 10 tries
 - Press OK
-> Firefox crashes due to a null pointer deref induced segfault

Marking as s-s for now just in case.
Attached file exampleRootCert0.der
The only interesting part of a gdb backtrace (the rest is all JS and XPConnect stuff):
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007f453ff463ee in nsNSSCertificateDB::SetCertTrust (this=0x7f45169026a0, cert=0x0, type=4, trusted=2) at /home/m-c_drive/mozilla-inbound/security/manager/ssl/src/nsNSSCertificateDB.cpp:992
> 992	  ScopedCERTCertificate nsscert(cert->GetCert());
Notes on my brief investigation:
- Pressing "Edit Trust..." opens editemailcert.xul
- editcerts.js::doLoadForEmailCert() is called as the onload for editemailcert.xul

- doLoadForEmailCert() calls nsNSSCertificateDB::FindCertByDBKey():
> function doLoadForEmailCert()
> {
>  var dbkey = self.name;
> 
>  //  Get the cert from the cert database
>  certdb = Components.classes[nsX509CertDB].getService(nsIX509CertDB);
>  cert = certdb.findCertByDBKey(dbkey, null);
>  ...
> }

- nsNSSCertificateDB::FindCertByDBKey() calls CERT_FindCertByIssuerAndSN(), which sometimes returns null:
  => The global var |cert| in editcerts.js gets assigned to null
> nsNSSCertificateDB::FindCertByDBKey(const char *aDBkey, nsISupports *aToken,
>                                    nsIX509Cert **_cert)
> {
> ...
>   cert = CERT_FindCertByIssuerAndSN(CERT_GetDefaultCertDB(), &issuerSN);
>   PR_FREEIF(keyItem.data);
>   if (cert) {
>     nsCOMPtr<nsIX509Cert> nssCert = nsNSSCertificate::Create(cert.get());
>     if (!nssCert)
>       return NS_ERROR_OUT_OF_MEMORY;
>     nssCert.forget(_cert);
>   }
>   return NS_OK;
> }

- User presses "OK" and editcerts.js::doEmailOK() is called as the ondialogaccept handler
- doEmailOK() calls nsNSSCertificateDB::SetCertTrust(), passing in a null pointer for the |cert| argument
> function doEmailOK()
> {
>   ...
>   certdb.setCertTrust(cert, nsIX509Cert.EMAIL_CERT, trustemail);
>   return true;
> }

- Null pointer deref occurs:
> nsNSSCertificateDB::SetCertTrust(nsIX509Cert *cert, 
>                                  uint32_t type,
>                                  uint32_t trusted)
> {
> ...
>   ScopedCERTCertificate nsscert(cert->GetCert());
> ...
> }
Null ptr deref after a fair amount of user interaction. We're not sure if it's even a sec bug but rating sec-low for now. Others feel free to weigh in.
Keywords: sec-low
This might be fixed by bug 1139205 (although it would still be a good idea for PSM code to null-check its arguments in general).
The UI for this was removed in Bug 1130418, and Bug 1168048 adds null checks.
I guess this can be resolved/opened up etc?
Group: core-security → crypto-core-security
Yep - I think we're good here.
Group: crypto-core-security
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: