Thunderbird fails on certificate path with circular references

RESOLVED FIXED

Status

()

Core
Security: PSM
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Armin Häberling, Assigned: kaie)

Tracking

1.8 Branch
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.10) Gecko/20070223 CentOS/1.5.0.10-0.1.el4.centos Firefox/1.5.0.10
Build Identifier: version 1.5.0.10 (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)
(Reporter)

Comment 1

11 years ago
Created attachment 260429 [details]
the mail message that causes the endless loop

Comment 2

11 years ago
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.
(Reporter)

Comment 5

11 years ago
Created attachment 261220 [details]
stack backtrace of the infinite loop

created a stack backtrace as requested in comment 3
Thanks.  The stack trace confirms that this is nsNSSCertificate::GetChain
called from JavaScript.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: psm
(Assignee)

Comment 7

11 years ago
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.
(Assignee)

Comment 9

11 years ago
(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+
(Assignee)

Comment 11

11 years ago
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.
(Assignee)

Updated

11 years ago
Depends on: 379559
(Assignee)

Comment 12

11 years ago
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.