User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20070223 CentOS/188.8.131.52-0.1.el4.centos Firefox/184.108.40.206 Build Identifier: version 220.127.116.11 (20070304) I've created a signed mail which contains the following certificates - Inter1 (issued by Inter3) - Inter2 (issued by Inter1) - Inter3 (issued by Inter2) - EndCert (issued by Inter3) This hierarchy contains a circular reference. The mail is signed with the EndCert. When I open the mail in Thunderbird, select View->Message Security Info and press "View Signature Certificate" Thunderbird does no longer respond and eats 100% of the CPU. So there must be a infinite loop somewere. Reproducible: Always Steps to Reproduce: 1. open the descibed mali in Thunderbird 2. select View->Message Security Info 3. press "View Signature Certificate" Actual Results: Thunderbird no longer responds (endless loop) Expected Results: Thunderbird displays the signer certificate (and the chain)
Haven't tried it yet, but I guess a similar denial of service attack could be produced if a web-server used such a certificate for https (t.b.c.)! For consolation, the Mozilla products are not alone: - http://bouncycastle.org/devmailarchive/msg07537.html - XCA: http://sourceforge.net/tracker/index.php?func=detail&aid=1693027&group_id=62274&atid=500025
I believe this is a bug in PSM. The problem is reported as happening only when the user attempts to look at the cert chain. The cert chain viewer window is PSM code. PSM contains a function to construct a cert chain, nsNSSCertificate::GetChain . It does not detect loops and so could loop forever as described. The flawed loop appears to have been added as a workaround for bug 77701. I'm sure the root cause of that bug was fixed LONG ago, and so the workaround (the new code added for that bug) should now be backed out. I hereby ask the submittors of this bug to reproduce it and kill the process in its infinite loop, and get a stack backtrace, and attach it to this bug. In particular, I want to know if the loop you're experiencing is this one in nsNSSCertificate::GetChai, or possibly another one.
Assignee: nobody → kengert
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: libraries
Version: unspecified → 1.8 Branch
Regarding the speculation that "a similar denial of service attack could be produced if a web-server used such a certificate for https": that is false. The cert chain verification functions do NOT have this flaw. So, this problem doesn't affect SSL clients or servers. It currently impacts only CMS (SMIME) users. I found a similar infinite loop in CERT_CertChainFromCert(), a function that constructs a cert chain without validating it, for the purpose of sending the constructed chain out (for SSL) or putting it into a file/message (e.g. PKCS7). That is the subject of bug 376748. Normally CERT_CertChainFromCert is only used to construct chains for one's own "user" certs (that is, for EE certs for which one has the private key). Consequently, this would normally only be a problem that users would make for themselves. That is, a user who put a circular cert path into his cert DB would put his own system into an infinite loop, and not someone else's system. As such, I would not consider it a vulnerability. But... The CMS (SMIME) library has a function named NSS_CMSSignedData_ImportCerts that attempts to import the signer's cert chain into the cert DB for future use. For reasons not entirely clear (but probably appropriate), that function calls CERT_CertChainFromCert to reconstruct the entire chain for the signer's cert, and then tries to import the entire chain. So that CMS function is vulnerable to circular chains received in signed emails. But this is still only a SMIME (email) vulnerability, not an SSL one.
Created attachment 261220 [details] stack backtrace of the infinite loop created a stack backtrace as requested in comment 3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 265575 [details] [diff] [review] Patch v1 Nelson, you proposed that avoiding the loop should be handled in PSM. However, you also propose to remove the loop at all, assuming that the workaround from bug 77701 is no longer necessary, because recent versions of NSS no longer crash in that scenario. This patch removes the workaround and switches the old code back on. Will CERT_GetCertChainFromCert avoid the loop?
Attachment #265575 - Flags: review?(nelson)
AFAIK, no bug was ever filed about the problem to which that comment refers, so I do not know if it was ever fixed or not.
(In reply to comment #8) > AFAIK, no bug was ever filed about the problem to which that comment refers, > so I do not know if it was ever fixed or not. If I understand bug 77701 correctly, the crash would show up when viewing an untrusted cert with the details tab of cert viewer. I tested that with the patch v1 applied, and it did not crash.
Comment on attachment 265575 [details] [diff] [review] Patch v1 Looks right to me. r=nelson
Attachment #265575 - Flags: review?(nelson) → review+
Thanks for the review. I plan to not check in until the a NSS release with patch from bug 376748 has been picked up by Mozilla trunk.
The time has come to check this in, as Mozilla trunk is now using NSS 3.12. Checked in.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.