477186 - Infinite loop in CERT_GetCertChainFromCert

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Loic]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

Firefox 3.0.6 was not responding when it tried to display details of a security certificate from COMODO CA Limited after it failed previously to obtain certificate identity.

Reproducible: Always

Steps to Reproduce:
1. Pre-step: clean your security certificates provided by COMODO CA Limited.
2. Go to this webpage (https) asking to accept a certificate from COMODO CA Limited.
Webpage from famous French hosting provider OVH (to order a server e.g.):
https://www.ovh.com/fr/commande/kimsufi.cgi?hard=083sk0
3. Error code: sec_error_unknown_issuer (invalid certificate used by OVH)
4. Click on Add the exception
5. Click on Obtain the certificate
6. Message: Unknown identity (invalid informations when the website is attempting to identify itself)
7. Click on Show

Actual Results:  
Firefox is not responding.
Forced to abort it by using Vista.

Expected Results:  
Displaying the details of the secutity certificate.

This crash can be reproduced when the certificate has been confirmed (without showing details).
Just go to certificate manager in Firefox (Server tab) and click on "Show" to display the details of COMODO CA Limited certificate relative to OVH webpage.

Comment 1

[Johnathan Nightingale [:johnath]]

Moving to Security:UI

Comment 2

[Rob Stradling]

The certificate for www.ovh.com is not invalid.

I can reproduce this problem with Firefox 3.0.6 / WinXP, but not with Firefox 3.0.5 / WinXP.  The problem seems to hinge on whether or not the cross-certificate issued by "UTN-USERFirst-Hardware" to "AddTrust External CA Root" is installed in the Firefox Certificate Manager.

When this cross-certificate is not installed, I can connect to all sites without any problems.

When this cross-certificate is installed with no trust purposes enabled, I see the following error message for many (perhaps all!) sites that use certificates that chain to UTN/AddTrust:
"<domain> uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
(Error code: sec_error_unknown_issuer)"
(Sometimes I see an OCSP error message instead, although I haven't managed to figure out how to reproduce this reliably.  I know that the relevant OCSP Responder is working correctly, so this is presumably a Firefox bug too).

When this cross-certificate is installed and the "This certificate can identify websites" trust purpose is enabled for it, Firefox hangs and starts consuming ~100% CPU when I attempt to navigate to any sites that use certificates that chain to UTN/AddTrust.  Attempting to close Firefox only makes the GUI disappear.  The process still consumes all of the CPU and needs to be manually killed!

The UTN->AddTrust cross-certificate is served by lots of SSL servers, and Firefox (PSM) automatically caches these (as Kai described to me in Bug #406755 Comment #3).
If you don't have a copy of it, simply browse to:
http://crt.comodoca.com/AddTrustUTNServerCA.crt

Comment 3

[Kai Engert [:KaiE:]]

You claim:

- Firefox 3.0.5 works fine
- Firefox 3.0.6 is broken

There was only one change in the security code between those versions:
We updated NSS to include one additional intermediate cert, explicitly set to UNTRUSTED.

You can make the following test to test whether this change was responsible:
- get file nssckbi.dll from Firefox 3.0.5
- copy it into your Firefox 3.0.6 directory

If this fixes your problem, the above change is the cause.

(Although it seems very unlikely).

Comment 4

[Kai Engert [:KaiE:]]

Attachment: dump of Rob's cert from comment 2

Comment 5

[Kai Engert [:KaiE:]]

Attachment: dump of cert we added in bug 471715

Comment 6

[Eddy Nigg (StartCom)]

It also works with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090205 Shiretoko/3.1b3pre

Comment 7

[JP Donnio]

I'm able to confirm I have this problem with
Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0) Gecko/2008061600 SUSE/3.0-1.2 Firefox/3.0

Not only on this OVH site, but also on https://www.gandi.net/

I have also tested using a different certificate chain on the previously affected site https://location-ski.twinner-sports.com/
That chain does not use the the
cross-certificate issued by "UTN-USERFirst-Hardware" to "AddTrust External CA
Root". 
Result: no more error.

I've also a report from a Mac user who is affected, I'll provide the version details when I get them.

Comment 8

[JP Donnio]

Here is the version details of the Mac reproducing this bug:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6 Ubiquity/0.1.5

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I think the issue reported by Rob Stradling in comment 2 is a different 
issue than the original subject of this bug, but I'm writing this comment
to ask the original reported to confirm that.  

As I understand it, this bug reports that the browser hangs up completely
and must be killed.  In Comment 2, Rob seems to be describing an issue 
with a cert that is identified as having an unknown or untrusted issuer,
but he does not mention a browser hang.  I think that is a separate issue,
and if so, it should be in a separate bug.  Clarifications from Rob or from
Loic would be good.

I cannot tell whether the issue described in comment 7 is a browser hang 
issue, or another unknown/untrusted issuer problem.  I suspect the latter.

Comment 10

[Loic]

Yes Nelson, you're right.

When Firefox tries to obtain the certificate, it fails to display its info like identity etc...
Anyway I think the certificate is valid because Firefox displays the HTTPS webpage and allows me to surf on it.

But if I try to display the info from the certificate (during the acquisition step OR after in the certificate manager), Firefox is not responding and Vista asks me to let it respond or quit.
Vista has to kill firefox.exe to quit.

I specified Fx 3.0.6 but I got this bug with 3.0.5 before the recent update.

Comment 11

[JP Donnio]

Nelson: there might be 2 bugs, but as far as comment 7 is concerned, I experience both issues: 
first unable to properly connect to the web site (Error code: sec_error_unknown_issuer) 
then if I do what Loic does, the browser freezes when I click on Display the cert.

Comment 12

[Loic]

@JP Donnio:
I forgot to mention I meet the same bug (freezing) when I visit the websites you provided in comment 7 (same certificate from COMODO).

Anyway I don't know if this issue is only relative to COMODO's certificates or it occcurs with another certificates.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

JP, Loic, thanks for your replies.  I think there are two separate bugs here. 
You both experience the hang, but one of your experiences a failure to 
complete a handshake, and the other doesn't.  So, the handshake failure is 
probably independent of the problem that occurs when trying to view a cert.

Let's let this bug be about the hang when displaying a cert.  
Rob, or JP, please file a separate bug about the issue that is thought to 
be related to the use of a particular CA cert, and CC me on that bug.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

After downloading the cert from Rob's URL in comment 2, simply attempting
to view that cert in cert manager causes the hang.  The hang occurs with 
100% CPU.  I have experienced this with a trunk browser from last October,
so I think it's not a very new problem.  I imagine this should not be too
hard to reproduce with a debugger.

I'm going to make an "educated guess" about the problem.  I think there is 
a loop somewhere, probably in PSM, that is attempting to find the cert 
issuer, and is in an infinite loop, because there are two certs that each
appear (to that code) to be each other's issuer.  I think this because the 
cert being downloaded has the same subject name as the issuer of the cert 
for the CA that issued this cert.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Note that, before the cert is installed in the cert DB, cert manager can
display the chain for that cert without any problem.  After the cert is 
installed, the attempt to display it causes the hang.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

Attachment: The other cert required to reproduce this.

I can reproduce this bug in FF 3.0.1 once I have downloaded TWO certs,
namely, the one Rob supplied in his comment above, and the one attached
herewith.  After both certs have been downloaded, without trust, any 
attempt to view either one will cause the hang.

Comment 17

[Honza Bambas (:mayhemer)]

We loop at security/nss/lib/certhigh/certvfy.c:1967, mozilla cvs trunk. As Nelson has foreseen.

Comment 18

[Honza Bambas (:mayhemer)]

The certs are cross-issued, one is issuer for the other and vise verse. We probably have to remember which certificate has already been walked or have a depth limit like a recursion limit for http redirect (easiest fix).

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

It's an NSS bug.  I thought we had found and fixed all these unbounded
loops to construct cert chains, but here's another one.  Sigh.

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Patch v1 for NSS Trunk

This is our standard method for avoiding infinite loops in cert chains.
Wan-Teh, please review this tiny patch.

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 361999 [details]
dump of cert we added in bug 471715

this cert is not relevant to this bug.

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 362315 [details] [diff] [review]
Patch v1 for NSS Trunk

Sorry, that was the wrong patch.

Comment 23

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch v2 for NSS trunk

This is the right patch.

Comment 24

[Wan-Teh Chang]

Comment on attachment 362317 [details] [diff] [review]
patch v2 for NSS trunk

r=wtc.

>+    while (cert != NULL && ++count < CERT_MAX_CERT_CHAIN) {

Nit: you have a minor off-by-one error here.  The test should
be
    ++count <= CERT_MAX_CERT_CHAIN
or
    count++ < CERT_MAX_CERT_CHAIN
otherwise, you will disallow a chain of exactly
CERT_MAX_CERT_CHAIN certs.

Comment 25

[Nelson Bolyard (seldom reads bugmail)]

Thanks for the quick review.
Checking in certhigh/certvfy.c; new revision: 1.67; previous revision: 1.66

Note to the readers here that this patch solves the infinite loop, which is 
the subject of this bug.  It does not address any issues of the certs 
issued by this CA being recognized as valid.  Another bug should be filed
about that issue.  It is likely to have a different resolution.

Comment 26

[Rob Stradling]

Nelson, Kai and Wan-Teh: Thanks for fixing this bug.

In reply to comment #9:
> ...In Comment 2, Rob seems to be describing an issue with a cert that is
> identified as having an unknown or untrusted issuer, but he does not mention a
> browser hang.

Actually, I did mention a browser hang, but your patch may well have fixed it. :-)

In reply to comment #25:
> this patch...does not address any issues of the certs issued by this CA being
> recognized as valid.  Another bug should be filed about that issue.  It is
> likely to have a different resolution.

I'll grab the latest CVS code and see what's still broken.

Comment 27

[Rob Stradling]

Using the latest Firefox CVS code (keeping NSS_CO_TAG = NSS_3_12_2_WITH_CKBI_1_73_RTM), the problems I described in Comment #2 are still reproducable.  This is expected.

Using the latest Firefox CVS code (with NSS_CO_TAG = HEAD), I cannot reproduce any of the problems I listed in Comment #2.  However, at the same time I notice a regression with the EV UI...

I still get the EV UI for https://www.verisign.com, https://www.thawte.com, https://www.geotrust.com, https://www.godaddy.com and https://www.entrust.net.

I no longer see the EV UI for https://www.globalsign.com, https://www.trustwave.com or https://www.networksolutions.com (I suspect this observation is covered by Bug #474606 - i.e. no OCSP URL quoted in these EV certificates).

However, I also no longer see the EV UI for any sites that use Comodo EV certificates!  e.g. https://secure.comodo.com, https://www.gandi.net, https://ev.tbs-x509.com.
These certificates *do* contain OCSP URLs in the AIA extension.
I've got "When an OCSP server connection fails, treat the certificate as invalid" ticked, and I don't see any OCSP errors when I browse to these URLs.

Nelson, Kai,
Would you like to handle this EV UI regression for Comodo EV certs in
1) This bug.
or
2) Bug #474606.
or
3) Some other existing bug.  Which one?
or
4) A new bug.
?

Comment 28

[Kai Engert [:KaiE:]]

> I no longer see the EV UI for https://www.globalsign.com,
> https://www.trustwave.com or https://www.networksolutions.com (I suspect this
> observation is covered by Bug #474606 - i.e. no OCSP URL quoted in these EV
> certificates).

Yes, I've updated the summary of bug 474606 to clarify that bug is related to CRLs.


> However, I also no longer see the EV UI for any sites that use Comodo EV
> certificates!  e.g. https://secure.comodo.com, https://www.gandi.net,
> https://ev.tbs-x509.com.

That's bad.
Thanks for your testing and the report.
I've filed new bug 479231

Comment 29

[Nelson Bolyard (seldom reads bugmail)]

By the way, I've filed bug 479508 about the unknown/untrusted issuer 
problem that is also shown by these same certs.