252268 - CRL DPCache problems with fake CA cert

Status: RESOLVED DUPLICATE of bug 233118

(NSS :: Libraries, defect)

Description

[Kai Engert (:KaiE:)]

This bug was found in the context of bug 249004.
(even with a patch applied, that prevents importing of fake certs into the perm
store).

In a testcase for bug 249004, the application examines a fake CA cert, where DN
is identical to one of the builtin and trusted certs.

Although the application does not import the fake cert into the perm store,
subsequent SSL access to a server, using a valid certificate by the trusted CA
cert, fails with error -8182.


More details, diagnostics, results of tests, and a suspicion about the cause.

test case 1:
- clean cert db
- start application
- use the application to look at the trusted builtin Thawte server CA cert
- examine the invalid fake cert, having same DN as the Tawte server CA cert
- access https://www.thawte.com
-> works fine, no errors

test case 2:
- clean cert db
- start application
- examine the invalid fake cert, having same DN as the Tawte server CA cert
- access https://www.thawte.com
-> while loading the various web site contents, error -8182 is shown for one of
the visited servers

test case 3:
- clean cert db
- start application
- examine the invalid fake cert, having same DN as the Tawte server CA cert
- restart application
- access https://www.thawte.com
-> works fine, no errors


Test case 3 shows the problem must be because of a temporary cert in memory.
Test case 2 makes it appear likely NSS still keeps the fake cert in memory and
uses it.
Test case 1 makes the suspicion appear more likely to me, because during some
initialization NSS already got to see the good CA.

During debugging of test 2, I saw that during the call to CERT_VerifyCert an
additional reference to the fake cert is created.
It appears the reference to the fake cert is created during the call to
SEC_CheckCRL, calling AcquireDPCache, creating some cache that will continue to
hold a reference to the fake cert.

Comment 1

[Robert Relyea]

Julien's most familiar with the CRL DPCache.

bob

Comment 2

[Julien Pierre]

Bob,

The CRL cache uses whatever issuer certificate is passed to it from
CERT_VerifyCert . It keeps a reference to the cert in order to be able to verify
updated CRLs in the future . This is required because not all code paths in the
cache have an issuer cert as input, for example, when a CRL is imported to a
token, there is no issuer cert argument, and the CRL is unverifiable without an
issuer cert, which delays its caching.

The main problem here is that the issuer cert passed from CERT_VerifyCert hasn't
been verified yet when the CRL cache is called. In this case, it turns out not
to be valid, but that fact isn't known until after the CRL cache is already
built. This is because of the loop in CERT_VerifyCert which goes from leaf to
root. All verification and revocation checking happens one level at a time.

The correct fix is to add more checks for the CRL issuer cert, so that an
invalid CRL cache does not get built. This is a duplicate of bug 233118 .


*** This bug has been marked as a duplicate of 233118 ***

Comment 3

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

If this is a dupe of a security'd bug, shoudln't this one be security'd as well?

Comment 4

[Julien Pierre]

Chris,

This defect can remain public because the test cases and what's been discussed
in this bug doesn't actually expose where the vulnerability is, whereas the
other bug does.