403698 - Crash with certs from certificates.starfieldtech.com

Status: RESOLVED DUPLICATE of bug 403685

(NSS :: Libraries, defect)

Description

[Kai Engert (:KaiE:)]

I was playing with PKIX_VerifyCert, and was attempting to verify the policy OID listed in that server cert.

From some earlier testing, I was expecting the cert to chain up to a root with subject/issuer:
"OU=Starfield Class 2 Certification Authority,O=\"Starfield Technologies, Inc.\",C=US"

When using PSM's view-pageinfo and view-page-cert, which are based on the classic NSS calls, it still lists that cert as the issuer.

However, libpkix based verification (which succeeds) finds a different root issuer: A cert from Valicert.


The trouble is, I get a crash when playing with these certs.
Steps to reproduce the crash:

- go to https://certificates.starfieldtech.com/images/trust_logo.gif
- view page info, view cert, details, close, close
- open cert manager, authorities tab, scroll to valicert
- click on the valicert cert that is stored in the soft device
- view, details, close, close
- try again to view cert
- crash

The place of the crash is random.
Once I crash in CERT_GetOrgName, another time I crashed in CERT_GetAVATag

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Kai, the fact that the old code and the new code will build chains up to 
different roots is expected.  It's why the approach of first testing the 
chain with the old code, then testing it again for EV with the new code
is doomed.  

Comment 2

[Kai Engert (:KaiE:)]

I know :-) And now we have a test case.
The difference in root cert lookup is not the point of this bug, it's just a detail of our current behavior.

The point of this bug is the crash.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Yay for having a test case! :)

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 0:
> Once I crash in CERT_GetOrgName, another time I crashed in CERT_GetAVATag

The code in the functions named above is very old NSS code.  It is called
both directly by applications, and may also be called from within libPKIX.
But a failure in those functions would not suggest to me a libPKIX problem.
(Neither does it eliminate libPKIX as a possible cause).  

I suspect that the value of the CERTName pointer being passed to these 
functions is bogus, causing those functions to rely on invalid pointers.
Considering the sequence of steps to reproduce, I suspect that the data
to which the CERTName pointer points has been freed.  

Comment 5

[Kai Engert (:KaiE:)]

By applying the patch in bug 483685, this testcase no longer crashes!

I'm therefore resolving this as a duplicate.