Last Comment Bug 204555 - CA cert with unusual extension in email signature causes crash.
: CA cert with unusual extension in email signature causes crash.
Status: RESOLVED FIXED
[adt3][3.7.7][3.4.4]
: crash, fixed1.4
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.8
: x86 All
: P1 critical (vote)
: 3.8.1
Assigned To: Nelson Bolyard (seldom reads bugmail)
: Bishakha Banerjee
Mentors:
Depends on: 174885
Blocks: 208038 208047
  Show dependency treegraph
 
Reported: 2003-05-05 20:14 PDT by Jeffrey Altman
Modified: 2004-03-25 20:30 PST (History)
10 users (show)
asa: blocking1.4+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
testcase in mbox format (19.09 KB, application/octet-stream)
2003-05-09 03:05 PDT, georgi - hopefully not receiving bugspam
no flags Details
(Working) testcase in mbox format (19.10 KB, application/octet-stream)
2003-05-19 08:48 PDT, Kai Engert (:kaie)
no flags Details
Patch v1 (565 bytes, patch)
2003-05-19 08:49 PDT, Kai Engert (:kaie)
nelson: review-
Details | Diff | Review
Alternate patch v1 (950 bytes, patch)
2003-05-20 17:28 PDT, Wan-Teh Chang
no flags Details | Diff | Review
patch v2 (5.43 KB, patch)
2003-05-20 23:11 PDT, Nelson Bolyard (seldom reads bugmail)
no flags Details | Diff | Review
CA cert with unusual extension (base64 encoded) (2.91 KB, text/plain)
2003-05-20 23:44 PDT, Nelson Bolyard (seldom reads bugmail)
no flags Details
patch v3. quite different from v1 and v2 (4.89 KB, patch)
2003-05-21 20:49 PDT, Nelson Bolyard (seldom reads bugmail)
wtc: review+
sspitzer: approval1.4+
Details | Diff | Review
Additional patch to nss/lib/certdb/secname.c (1.69 KB, patch)
2003-05-24 00:28 PDT, Nelson Bolyard (seldom reads bugmail)
wtc: review+
asa: approval1.4+
Details | Diff | Review
Additional patch to nss/lib/certdb/genname.c (19.21 KB, patch)
2003-05-28 00:51 PDT, Nelson Bolyard (seldom reads bugmail)
wtc: review+
asa: approval1.4+
Details | Diff | Review

Description Jeffrey Altman 2003-05-05 20:14:44 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

E-mails from Microsoft recently were required to go through an additional set of
SMTP relays in order to pass through virus filters.  When these e-mails are then
sent through a mailing list the number of Received: headers reaches 12 or more.
 We believe that a buffer is being overwritten while the mail is being
processed.  We do have not examined the overwrite to determine whether or not it
can be exploited.

Reproducible: Always

Steps to Reproduce:
Load this e-mail from an IMAP server with spam filtering on

Return-Path: <owner-ietf-krb-wg@atalanta.ctd.anl.gov>
Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4])
	by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h3GHfBoN011793
	for <jaltman@columbia.edu>; Wed, 16 Apr 2003 13:41:11 -0400 (EDT)
Received: (from majordom@localhost)
      by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id MAA28939
      for ietf-krb-wg-outgoing; Wed, 16 Apr 2003 12:38:55 -0500 (CDT)
Received: from hermes.ctd.anl.gov (localhost [127.0.0.1])
      by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA28932
      for <ietf-krb-wg@achilles.ctd.anl.gov>; Wed, 16 Apr 2003 12:38:52 -0500 (CDT)
Received: from hermes.ctd.anl.gov (localhost [127.0.0.1])
	by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA29084
	for <ietf-krb-wg@achilles.ctd.anl.gov>; Wed, 16 Apr 2003 12:38:52 -0500 (CDT)
Received: from mailrelay.anl.gov (mailrelay.anl.gov [130.202.101.22])
	by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA29081
	for <ietf-krb-wg@anl.gov>; Wed, 16 Apr 2003 12:38:52 -0500 (CDT)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by localhost.ctd.anl.gov (Postfix) with ESMTP
	id 1D3CA5F0FE9; Wed, 16 Apr 2003 12:38:52 -0500 (CDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by mailrelay.anl.gov (Postfix) with ESMTP id 64C185F0FE9
	for <ietf-krb-wg@anl.gov>; Wed, 16 Apr 2003 12:38:51 -0500 (CDT)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by
mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624);
	 Wed, 16 Apr 2003 10:38:50 -0700
Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan
E-Mail VirusWall NT); Wed, 16 Apr 2003 10:38:50 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by
inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600);
	 Wed, 16 Apr 2003 10:38:50 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39])
by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600);
	 Wed, 16 Apr 2003 10:38:49 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com
([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with
Microsoft SMTPSVC(6.0.3788.0);
	 Wed, 16 Apr 2003 10:38:48 -0700
Content-class: urn:content-classes:message
Subject: RE: AES and SHA-1 timing 
MIME-Version: 1.0
Date: Wed, 16 Apr 2003 10:38:52 -0700
Content-Type: multipart/signed;
	boundary="----=_NextPart_000_0036_01C30404.5CBD5C80";
	micalg=SHA1;
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8
Message-ID:
<91D7F2CEE3425A4A9D11311D09FCE2460196A80E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: yes
Thread-Topic: AES and SHA-1 timing 
Thread-Index: AcMD7Dei7A27+tKGTXyn65BPsrcpAgAUjOUg
From: "Paul Leach" <paulle@windows.microsoft.com>
To: "Marcus Watts" <mdw@umich.edu>, <ietf-krb-wg@anl.gov>
X-OriginalArrivalTime: 16 Apr 2003 17:38:48.0461 (UTC) FILETIME=[0974DBD0:01C3043F]
X-Spam-Status: No, hits=-100.0 required=5.7
	tests=USER_IN_WHITELIST
	version=2.53
X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp)
Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov
Precedence: bulk
X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang)

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01C30404.5CBD5C80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I hope it is clear that the iteration count in the AES string-to-key
cipher suite can be precomputed by the KDC when the password is changed;
thus, it should not normally have any significant impact on KDC load.
(Unless you have a really high volume of password change operations.)

Finally, the iteration count is just the default -- it can be changed if
a large number of really slow machines are in one's environment, and if
the increased risk of password breakability can be accepted. 

------=_NextPart_000_0036_01C30404.5CBD5C80
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIpCjCCA7Ew
ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx
EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv
b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R
JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA
ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU
J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0
WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S
jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC
AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD
ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs
I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL
xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D
plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR
S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg
MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF
TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN
MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj
cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh
rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj
ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/
BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG
AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud
IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw
1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D
Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh
MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln
dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS
ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw
Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50
ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4
MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi
b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl
cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9
Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5
MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl
cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk
aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml
aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBtAwggY5oAMCAQICChWC27AA
AgAdDLIwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO
MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMjA5MTEwMTE2MDJa
Fw0wMzA5MTEwMTE2MDJaMIHdMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ
bWljcm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRAw
DgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5TWFuYWdlZDERMA8GA1UECxMITG93VENP
LUUxEzARBgNVBAMTClBhdWwgTGVhY2gxKzApBgkqhkiG9w0BCQEWHHBhdWxsZUB3aW5kb3dzLm1p
Y3Jvc29mdC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALfXtAe4rPaOte+60lbRKMsa
tUQWvwkrf+Pivmnc7mY/s2QcLnXpztWu7p2zlVct+IvYlF+sR5k929NVgDwUYqA1Mzuakg94aFjz
0a7QoRGmUR6QnzbcG6CJEXEgjpnUIhvs0kFS4wyN1QE2+VS8Cd3BsYqvpOIG737DpY+DheI1AgMB
AAGjggQmMIIEIjALBgNVHQ8EBAMCBaAwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAw
DgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBQEnI/IeQPDcIBQ
4jjAFnC6zEaHUjApBgkrBgEEAYI3FAIEHB4aAFMAbQBhAHIAdABjAGEAcgBkAFUAcwBlAHIwHwYD
VR0jBBgwFoAUi9HNYfHpr468kdBA6im/5i6FQFcwggGIBgNVHR8EggF/MIIBezCCAXegggFzoIIB
b4aBz2xkYXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSgyKSxDTj1XSElDQTMsQ049Q0RQLENO
PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9
bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxp
c3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZNaHR0cDovL3doaWNhd2Vi
Lm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9OVERFVkNSTHMvTlRERVYlMjBJU1NVRTMlMjBDQSgy
KS5jcmyGTGh0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv
TlRERVYlMjBJU1NVRTMlMjBDQSgyKS5jcmwwggFUBggrBgEFBQcBAQSCAUYwggFCMIHFBggrBgEF
BQcwAoaBuGxkYXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVibGljJTIw
S2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1j
b3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNl
cnRpZmljYXRpb25BdXRob3JpdHkweAYIKwYBBQUHMAKGbGh0dHA6Ly93aGljYTMubnRkZXYuY29y
cC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvV0hJQ0EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNv
bV9OVERFViUyMElTU1VFMyUyMENBKDIpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEF
BQcDBAYIKwYBBQUHAwIwUwYDVR0RBEwwSqAqBgorBgEEAYI3FAIDoBwMGnBhdWxsZUBudGRldi5t
aWNyb3NvZnQuY29tgRxwYXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMA0GCSqGSIb3DQEBBQUA
A4GBAEWTH/l9t20BxpXengbCu5JV2++sbzBbiyWIAU5MKaVDFzQPzP30rKwhVl4yCIdgAs30tCF2
6t3PSF9JA0i3wF2xqXfhOSyGs4u+v0LPS3Fu09tjxDHAQNwUK6AuLOsReLZ3qz5s+1hWOeVNHLma
C8ogdSpfOQPOC17OHaHT9BpRMIIIGzCCBwOgAwIBAgIKKMbncgABAAAANTANBgkqhkiG9w0BAQUF
ADBMMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcG
A1UEAxMQTlRERVYgU0EgUm9vdCBDQTAeFw0wMjEwMTAxNjMzMDBaFw0wNTEwMTAxNjQzMDBaMGEx
CzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQD
EyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMIIBtzCCASsGByqGSM44BAEw
ggEeAoGBAPoSz3u7mLB5rhlH5CE5AalrBl6Ntst+vZLNPRPhI8ABrNuHKYWlR6hWd/ikP5IMgDQr
7DUpJrrdv4Z2T1pJPVEHIxCua3HTX/o+XVGTZXdBv4x+OhHLmt11KcTy9B+0tpg3psJC4m+taONa
bd+yw/EB9AoPldGdHoGBBSGOdALjAhUAmE+UPbJ1WtXpFK2UwmM6G/zo60MCgYBmyg997xQQPnCr
4IraxqUi5sXXsvSPvimwO/UEFxJwAiWS8OUunvnh7Gd0/scD5YNkVAsbRYF+XNgyYVCsYusC1LH8
DvoOzq4Hz8lg9K/2kA80v2Skr4DH1EFM2JG3J9Hbq362Dk9i8V6HAZEA/P8kB9/J+cI1LoXlWtfw
5uaCmAOBhQACgYEAokrSViTIQt7ZG0Ytjr2GLccq5bTzDsmUdROQz1qi9eb5cOIYa2YXgE6cmZTI
IFOLx6bPdgbwZSAsOfBQofQoLG3vJeQcGsA/vj7wzjmzlaImYsBF9OZRFKl7C3r/TLShHXBTQHo1
6zcCGuLCXhQvOsrjJhlKvhvR5fMmNpOK4jmjggRTMIIETzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud
DgQWBBTivgNw1Ysg0kFEaq/myHdxWiUAHzALBgNVHQ8EBAMCAYYwEgYJKwYBBAGCNxUBBAUCAwQA
BTAjBgkrBgEEAYI3FQIEFgQU1lIoN1kh422F4hJqLWNtqmi8a0AwGQYJKwYBBAGCNxQCBAweCgBT
AHUAYgBDAEEwHwYDVR0jBBgwFoAUiMnNnJw6IoDq5C3aFUcv9fvEvJswggGZBgNVHR8EggGQMIIB
jDCCAYigggGEoIIBgIaB2WxkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKSxDTj13
aGljYXNhcm9vdGNhLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl
cyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9j
ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9u
UG9pbnSGUWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9s
bC9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEpLmNybIZPaHR0cDovL3doaWNhMy5udGRldi5jb3Jw
Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEpLmNybDCC
AekGCCsGAQUFBwEBBIIB2zCCAdcwgcgGCCsGAQUFBzAChoG7bGRhcDovLy9DTj1OVERFViUyMFNB
JTIwUm9vdCUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl
cyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9j
QUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhAYI
KwYBBQUHMAKGeGh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVu
cm9sbC93aGljYXNhcm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIw
Um9vdCUyMENBKDEpLmNydDCBggYIKwYBBQUHMAKGdmh0dHA6Ly93aGljYTMubnRkZXYuY29ycC5t
aWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5jb3JwLm1pY3Jvc29m
dC5jb21fTlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKS5jcnQwEQYDVR0gBAowCDAGBgRVHSAAMA0G
CSqGSIb3DQEBBQUAA4IBAQA0wmQlGbxPwheWF+0oj8v1hjBbV13gmBK/2Oy0q2OcgC/o+GSkKK+5
S36xOxTvVIBio37Pi6jtJI8WneO9ONcLQK5NHuUV3j9FFtCM2TnLbq/OJHu+rKrYIBRYAjn3y6oW
PaZQnH1Ug6Qa54ACEl1bocfKBM6bVNlJKnB+WRpnwb4MrXQinvr0rYrlYH+Z7xECHo+aJ9qnp7cX
XzELF57Y9qBBbqY5keifWFfX+NxhFpRrgwtS6LtdIPOInQLG2kPoY8QafHvTSBj4IuSxdaN+d0d9
n1ODnN4IKRhRYiVSpwP7aoLrK3FelYjdLEH7XQC2q+T41duYgNhWl0Dkf26XMIIIUzCCCBOgAwIB
AgIKFDyh8QAEAAACDjAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3Nv
ZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5h
dGUgV2hpY2EyMB4XDTAyMDkxMTIxMjkxMVoXDTA0MDkxMTIxMzkxMVowgZwxEzARBgNVBAgTCldh
c2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEbMBkGA1UECxMS
Q29ycG9yYXRlIFNlY3VyaXR5MR8wHQYDVQQDExZJVEcgTlRERVYgTGV2ZWwgMiBDQSAxMSEwHwYJ
KoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDK3WSfPiHuUTHaYPDEpnk3Rb16aCgk8MVvtyqDzjO1xJrR4XzXq+HYnbFG4YD/89eWe6Fn
A2j7coULWcw3JuHGTTvWKYYhQ7Y3c7HeMw70Hh2X9nCuKZS8HuADCBkp9Qn4MW2ebwlx5qD5RuRN
NwypZ9SLzbC1uBELuJ55NwMYCX3wQUGfipGEC0nQcy2vxhlKfno1jZOcx+yUm3/78A8f49iJjDBF
bIdw4nBBPtfH6y7TTjBLNDMk28QFFKCJoEuaW7F0ToGLDI0ZJ0wL3FdF6u3Up29ipiRePu5HYTlp
lU51R/UU7JXP9kgq2eJE/Ep0w2wNbARV3Vof3D2MCREzAgMBAAGjggWrMIIFpzCBhAYJKwYBBAGC
NxUKBHcwdTAKBggrBgEFBQcDBDAKBggrBgEFBQcDAjAMBgorBgEEAYI3KgIBMAwGCisGAQQBgjcU
AgIwCgYIKwYBBQUHAwEwDAYKKwYBBAGCNwoDBDAKBggrBgEFBQgCAjAMBgorBgEEAYI3FAIBMAsG
CSsGAQQBgjcVBTCCAQIGA1UdHgEB/wSB9zCB9KCB8TAmoCQGCisGAQQBgjcUAgOgFgwULm50ZGV2
Lm1pY3Jvc29mdC5jb20wJqAkBgorBgEEAYI3FAIDoBYMFEBudGRldi5taWNyb3NvZnQuY29tMCug
KQYKKwYBBAGCNxQCA6AbDBkubnRkZXYuY29ycC5taWNyb3NvZnQuY29tMCugKQYKKwYBBAGCNxQC
A6AbDBlAbnRkZXYuY29ycC5taWNyb3NvZnQuY29tMAKBADAWghQubnRkZXYubWljcm9zb2Z0LmNv
bTAbghkubnRkZXYuY29ycC5taWNyb3NvZnQuY29tMASkAjAAMAKGADAChwAwbAYDVR0lBGUwYwYI
KwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3KgIBBgorBgEEAYI3FAICBggrBgEFBQcDAQYKKwYB
BAGCNwoDBAYIKwYBBQUIAgIGCisGAQQBgjcUAgEGCSsGAQQBgjcVBTA2BgkrBgEEAYI3FQcEKTAn
Bh8rBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFQEZAgFuAgEAMAsGA1UdDwQEAwIBhjAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBSJxTTWfvOjehK5aUoXNz82pJexAjAdBgkrBgEEAYI3FAIE
EB4OAEMAcgBvAHMAcwBDAEEwHwYDVR0jBBgwFoAU4r4DcNWLINJBRGqv5sh3cVolAB8wggFpBgNV
HR8EggFgMIIBXDCCAVigggFUoIIBUIZkaHR0cDovL3doaWNhMi5udGRldi5jb3JwLm1pY3Jvc29m
dC5jb20vQ2VydEVucm9sbC9OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hp
Y2EyKDQpLmNybIaB52xkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0
ZSUyMFdoaWNhMig0KSxDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz
LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3Nv
ZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxE
aXN0cmlidXRpb25Qb2ludDCCAYYGCCsGAQUFBwEBBIIBeDCCAXQwgd0GCCsGAQUFBzAChoHQbGRh
cDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyLENOPUFJ
QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u
LERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/
b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBkQYIKwYBBQUHMAKGgYRodHRwOi8v
d2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhMi5udGRldi5j
b3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdo
aWNhMig0KS5jcnQwCQYHKoZIzjgEAwMvADAsAhRaLZp2dcfe6nBfd9/NNngDpZHeTQIULNKpFBWL
jC3FWsWDtboFL51FNu8wgghxMIIHWaADAgECAgoptgwUAAAAAAvJMA0GCSqGSIb3DQEBBQUAMIGc
MRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3Nv
ZnQxGzAZBgNVBAsTEkNvcnBvcmF0ZSBTZWN1cml0eTEfMB0GA1UEAxMWSVRHIE5UREVWIExldmVs
IDIgQ0EgMTEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMB4XDTAyMDkxOTIwMDI1
OFoXDTAzMDkxOTIwMDI1OFowgd0xEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZ
FgltaWNyb3NvZnQxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRUwEwYKCZImiZPyLGQBGRYFbnRkZXYx
EDAOBgNVBAsTB0lNLVNlbGYxFzAVBgNVBAsTDkxpZ2h0bHlNYW5hZ2VkMREwDwYDVQQLEwhMb3dU
Q08tRTETMBEGA1UEAxMKUGF1bCBMZWFjaDErMCkGCSqGSIb3DQEJARYccGF1bGxlQHdpbmRvd3Mu
bWljcm9zb2Z0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAziH54lXGcWawhNm9t/AT
rqP2Y98RXkGiaZpybBsokiHrJg8/MTQtvBj9KV/9mi11pZMk57BtSb7vBmW/Y3gFUYknaw/IRbPo
xukV9pxj2AeVG30aqS6xwQLTlZvTgfosqoz/LNIauCvLAvnKHJVV9G0gyEOgEyol1ejZnZT3kZMC
AwEAAaOCBPQwggTwMAsGA1UdDwQEAwIHgDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIA
gDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwNQYDVR0lBC4wLAYIKwYBBQUH
AwQGCisGAQQBgjcqAgEGCisGAQQBgjcUAgIGCCsGAQUFBwMCMB0GA1UdDgQWBBSveyBQJ+9rMmTI
qxi3Yv0HJpQgBzAfBgNVHSMEGDAWgBSJxTTWfvOjehK5aUoXNz82pJexAjCCAY8GA1UdHwSCAYYw
ggGCMIIBfqCCAXqgggF2hoHebGRhcDovLy9DTj1JVEclMjBOVERFViUyMExldmVsJTIwMiUyMENB
JTIwMSxDTj1yZWRpdGdjYWIxMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049
U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxE
Qz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3Ry
aWJ1dGlvblBvaW50hltodHRwOi8vcmVkaXRnY2FiMTEubnRkZXYuY29ycC5taWNyb3NvZnQuY29t
L0NlcnRFbnJvbGwvSVRHJTIwTlRERVYlMjBMZXZlbCUyMDIlMjBDQSUyMDEuY3JshjZodHRwOi8v
Y3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvbnRkZXZsMmNhMS5jcmwwggG3BggrBgEF
BQcBAQSCAakwggGlMIHSBggrBgEFBQcwAoaBxWxkYXA6Ly8vQ049SVRHJTIwTlRERVYlMjBMZXZl
bCUyMDIlMjBDQSUyMDEsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp
Y2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29t
P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGN
BggrBgEFBQcwAoaBgGh0dHA6Ly9yZWRpdGdjYWIxMS5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20v
Q2VydEVucm9sbC9yZWRpdGdjYWIxMS5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fSVRHJTIwTlRE
RVYlMjBMZXZlbCUyMDIlMjBDQSUyMDEuY3J0MD4GCCsGAQUFBzAChjJodHRwOi8vd3d3Lm1pY3Jv
c29mdC5jb20vcGtpL21zY29ycC9udGRldmwyY2ExLmNydDA8BgkrBgEEAYI3FQcELzAtBiUrBgEE
AYI3FQiGuYgUhvKOIYedlRyF94Jk16ZvgXrojxqB1bUgAgFkAgEFMEMGCSsGAQQBgjcVCgQ2MDQw
CgYIKwYBBQUHAwQwDAYKKwYBBAGCNyoCATAMBgorBgEEAYI3FAICMAoGCCsGAQUFBwMCMFMGA1Ud
EQRMMEqgKgYKKwYBBAGCNxQCA6AcDBpwYXVsbGVAbnRkZXYubWljcm9zb2Z0LmNvbYEccGF1bGxl
QHdpbmRvd3MubWljcm9zb2Z0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAQFcbgYkE2up56ZijDN7P
10+ieuL+CSuIz2ZCgDwdyHQlcFBIdSSD7tJszEO28e37JvkbdGzFe9xUJJ5IAL7xiGs138IejcFT
2BHRKztV1NrE2bFsLtEwM35zf0PfWoR+gH6eFMB3u4bj6K1xUq/kT/5xZxlaYf6xpP/EJVlcK/+Y
78p/bLVNGk3hP8j0NBsa02OFTEcoCBpDh9D4tV1vZ3kZZBTYCwVm3CWDwPFgW877gGS+kJlfN4/b
EbACsljgXAqtt5HcImnrqtEptfkwa+gY7dZbcm9QU4HZOSQCiJR0NDj6gCAa47kxncv6OoJwUe+y
4zZA5SEZMzIH2jYAfjGCAvIwggLuAgEBMIGrMIGcMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYD
VQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxGzAZBgNVBAsTEkNvcnBvcmF0ZSBTZWN1
cml0eTEfMB0GA1UEAxMWSVRHIE5UREVWIExldmVsIDIgQ0EgMTEhMB8GCSqGSIb3DQEJARYScGtp
dEBtaWNyb3NvZnQuY29tAgoptgwUAAAAAAvJMAkGBSsOAwIaBQCgggGcMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDQxNjE3Mzg0N1owIwYJKoZIhvcNAQkEMRYE
FHE7e03e8jQQQV8hXtuhMJfnzlK9MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYFKw4D
AhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MAoGCCqGSIb3DQIFMGgGCSsGAQQBgjcQBDFbMFkwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1p
Y3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQQIKFYLbsAAC
AB0MsjBqBgsqhkiG9w0BCRACCzFboFkwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m
dDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQQIKFYLbsAACAB0MsjAN
BgkqhkiG9w0BAQEFAASBgA8DyRsJ5d5r0Xl3PE8go4WzixWjx34iBg2wpLOu5Z/OjcOwSRsyhj3T
ckKKEfFlSDXKWUuiF4SK/QcpiqMRAo4YMibtrfgty6IqpCoeHoptjDT+RN+3TFN1h2H3CxgvfGB6
waRTuqrVQXSeG7PEYSx1qc7TeF9EOZB3Q/D0vGrHAAAAAAAA

------=_NextPart_000_0036_01C30404.5CBD5C80--


Actual Results:  
The results are unpredictable depending on the e-mail.  Memory is being
overwritten.  Sometimes mozilla crashes.  Sometimes it refuses to shutdown. 
Sometimes it becomes completely unresponsive.

Expected Results:  
mozilla should have downloaded the e-mail and allowed it to be read.
Comment 1 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-05-08 18:33:24 PDT
Georgi, can you test this?

Reporter, can you try this with Mozilla 1.4b?
Comment 2 georgi - hopefully not receiving bugspam 2003-05-09 02:47:03 PDT
I crash on linux on 1.3 but don't crash on recent nightly (default build,
without PSM/SMIME)
The stack is:
------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 1343)]
0x43d85caf in CERT_CopyName () from /opt/mozilla1-3/libnss3.so
(gdb) info stack
#0  0x43d85caf in CERT_CopyName () from /opt/mozilla1-3/libnss3.so
#1  0x43d82e3e in CERT_DecodeGeneralName () from /opt/mozilla1-3/libnss3.so
#2  0x43d82f85 in CERT_DecodeGeneralName () from /opt/mozilla1-3/libnss3.so
#3  0x43d830c2 in CERT_DecodeGeneralName () from /opt/mozilla1-3/libnss3.so
#4  0x43d838cc in CERT_DecodeGeneralName () from /opt/mozilla1-3/libnss3.so
#5  0x43d5fb38 in CERT_FindCertIssuer () from /opt/mozilla1-3/libnss3.so
#6  0x43d5fc89 in CERT_FindCertIssuer () from /opt/mozilla1-3/libnss3.so
#7  0x43d6076e in CERT_VerifyCert () from /opt/mozilla1-3/libnss3.so
#8  0x43c3f4e4 in NSS_CMSSignerInfo_Destroy () from /opt/mozilla1-3/libsmime3.so
#9  0x43c3e9d7 in NSS_CMSSignedData_VerifySignerInfo () from
/opt/mozilla1-3/libsmime3.so
#10 0x43d0247a in NSGetModule () from /opt/mozilla1-3/components/libpipnss.so
#11 0x43d0234b in NSGetModule () from /opt/mozilla1-3/components/libpipnss.so
#12 0x435594fe in NSGetModule () from /opt/mozilla1-3/components/libmime.so
#13 0x4353d686 in NSGetModule () from /opt/mozilla1-3/components/libmime.so
#14 0x4353cf2b in NSGetModule () from /opt/mozilla1-3/components/libmime.so
#15 0x43532abd in NSGetModule () from /opt/mozilla1-3/components/libmime.so
#16 0x4353c749 in NSGetModule () from /opt/mozilla1-3/components/libmime.so
#17 0x435474cd in NSGetModule () from /opt/mozilla1-3/components/libmime.so
#18 0x435515b0 in NSGetModule () from /opt/mozilla1-3/components/libmime.so
#19 0x416cc5ba in NSGetModule () from /opt/mozilla1-3/components/liburiloader.so
#20 0x4087e354 in NSGetModule () from /opt/mozilla1-3/components/libnecko.so
#21 0x40863b36 in NSGetModule () from /opt/mozilla1-3/components/libnecko.so
#22 0x408635f4 in NSGetModule () from /opt/mozilla1-3/components/libnecko.so
#23 0x404c0647 in PL_HandleEvent () from /opt/mozilla1-3/libxpcom.so
#24 0x404c0563 in PL_ProcessPendingEvents () from /opt/mozilla1-3/libxpcom.so
#25 0x404c14a8 in nsEventQueueImpl::ProcessPendingEvents () from
/opt/mozilla1-3/libxpcom.so
#26 0x410787d3 in NSGetModule () from /opt/mozilla1-3/components/libwidget_gtk.so
#27 0x410784cd in NSGetModule () from /opt/mozilla1-3/components/libwidget_gtk.so
#28 0x402ac076 in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#29 0x402ad97e in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#30 0x402ade59 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#31 0x402ae0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0
#32 0x401ac6df in gtk_main () from /usr/lib/libgtk-1.2.so.0
#33 0x41078bbc in NSGetModule () from /opt/mozilla1-3/components/libwidget_gtk.so
#34 0x4104e996 in NSGetModule () from /opt/mozilla1-3/components/libnsappshell.so
#35 0x08057de9 in getCountry ()
#36 0x080584d5 in main ()
#37 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
------------------------------------------------------------

My guess is this has nothing to do with headers, but the problem is in
SMIME/libnss. Shall check with long headers.

This exact my crash looks like NULL dereference.

Comment 3 georgi - hopefully not receiving bugspam 2003-05-09 03:05:41 PDT
Created attachment 122838 [details]
testcase in mbox format

Copy the testcase in your "local folders" and open the only message in the
folder
Comment 4 georgi - hopefully not receiving bugspam 2003-05-09 03:07:48 PDT
Probably this has nothing to do with spam checking. I crash in local folders
even if the message is marked as read.
Comment 5 georgi - hopefully not receiving bugspam 2003-05-09 03:34:03 PDT
I don't see any problem opening messages with thousands of "Received:" headers.
Probably SMIME problem.
Comment 6 Jeffrey Altman 2003-05-09 04:37:21 PDT
I can confirm the crash occurs with 1.4b when some of the messages from this
author are opened in any folder.  The spam checking is a red herring.  It is
simply the catalyst for the message to be opened.

Comment 7 georgi - hopefully not receiving bugspam 2003-05-09 08:12:04 PDT
Reporter, are all messages which crash signed or encrypted (if you can determine
this)?
My guess is null dereference in SMIME.
Comment 8 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-05-09 09:23:29 PDT
Thanks Georgi!

I can reproduce this crash using the mailbox format message on Win2k, debug
build with PSM from last week. It is a null pointer reference in secname.c:

    while ((frdn = *rdns++) != 0) { // <= crash here

This an unexploitable crash, so removing security flag.

Reassigning to PSM.
Comment 9 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-05-09 09:29:32 PDT
Nominating for nsbeta1 and 1.4 final since I believe a fair number of people
receive these emails. With spam filtering on you basically can not use mail.
Comment 10 georgi - hopefully not receiving bugspam 2003-05-09 10:25:38 PDT
I think I tracked the crash in the reporter's testcase.
It seems NULL pointer dereference in secname.c:473
----------------------
(gdb) frame 7
#7  0x435f2e0f in CERT_CopyName (arena=0x8cb80e8, to=0x8cbef90, from=0x8cc3a10)
    at secname.c:473
473         while ((frdn = *rdns++) != 0) {
Current language:  auto; currently c
(gdb) p rdns
$1 = (struct CERTRDNStr **) 0x0
-----------------------
Comment 11 Jeffrey Altman 2003-05-09 13:00:03 PDT
All e-mails which crash are S/MIME 

The source code error you found looks plausible.

Comment 12 Jeffrey Altman 2003-05-15 20:59:22 PDT
Is this supposed to be fixed in the daily builds?

I'm still seeing the problem with build 2003051504.

Comment 13 Asa Dotzler [:asa] 2003-05-16 10:07:51 PDT
Stephane, can you look into this and let us know what can be done? It's a
Mozilla 1.4 blocker. Thanks.
Comment 14 Kai Engert (:kaie) 2003-05-19 08:24:51 PDT
Note the attached message is corrupted. It contains headers, whose lines
continue on the following line, but the following line does not start indented.
While I can read this message after having it copied to my local folders, I can
not copy it to my IMAP server, because the server complains about corrupted headers.

I fixed the problem by manually editing the file to have indented lines where
appropriate and finally was able to copy it to the IMAP server.

I don't crash on Linux.
But I confirm, I'm crashing on Windows with this message!

Investigating.
Comment 15 Kai Engert (:kaie) 2003-05-19 08:31:24 PDT
Confirming, the crash is in NSS. Over to NSS.

In CERT_CopyName, from->rdns is zero, but the function dereferences without
checking.

Please let me know if you want me to help debugging and provide contents of
additional variables.


CERT_CopyName(PLArenaPool * 0x04c425d0, CERTNameStr * 0x04e820dc, CERTNameStr *
0x04fc3cbc) line 473 + 3 bytes
CERT_CopyGeneralName(PLArenaPool * 0x04c425d0, CERTGeneralNameStr * 0x04e820d8,
CERTGeneralNameStr * 0x04fc3cb8) line 695 + 23 bytes
CERT_CopyNameConstraint(PLArenaPool * 0x04c425d0, CERTNameConstraintStr *
0x04e820d8, CERTNameConstraintStr * 0x04fc3cb8) line 758 + 17 bytes
CERT_GetNameConstriantByType(CERTNameConstraintStr * 0x04fc3840, int 5,
CERTNameConstraintStr * * 0x0012f818, PLArenaPool * 0x04c425d0) line 862 + 17 bytes
CERT_CompareNameSpace(CERTCertificateStr * 0x04edc998, CERTGeneralNameStr *
0x04e817c0, SECItemStr * 0x04f6ee58, PLArenaPool * 0x04c425d0, NSSTrustDomainStr
* 0x05144e80) line 1286 + 25 bytes
cert_VerifyCertChain(NSSTrustDomainStr * 0x05144e80, CERTCertificateStr *
0x04e7a880, int 1, int * 0x00000000, int 4, __int64 1053357681792609, void *
0x00000000, CERTVerifyLogStr * 0x00000000, int 1, int * 0x00000000) line 953 +
25 bytes
CERT_VerifyCertChain(NSSTrustDomainStr * 0x05144e80, CERTCertificateStr *
0x04e7a880, int 1, int 4, __int64 1053357681792609, void * 0x00000000,
CERTVerifyLogStr * 0x00000000) line 1001 + 43 bytes
CERT_VerifyCert(NSSTrustDomainStr * 0x05144e80, CERTCertificateStr * 0x04e7a880,
int 1, int 4, __int64 1053357681792609, void * 0x00000000, CERTVerifyLogStr *
0x00000000) line 1610 + 37 bytes
NSS_CMSSignedData_ImportCerts(NSSCMSSignedDataStr * 0x05169a30,
NSSTrustDomainStr * 0x05144e80, int 4, int 1) line 510 + 34 bytes
nsCMSMessage::CommonVerifySignature(unsigned char * 0x05169960, unsigned int 20)
line 362 + 19 bytes
Comment 16 Kai Engert (:kaie) 2003-05-19 08:48:08 PDT
Created attachment 123695 [details]
(Working) testcase in mbox format
Comment 17 Kai Engert (:kaie) 2003-05-19 08:49:16 PDT
Created attachment 123696 [details] [diff] [review]
Patch v1

This patch fixes the crash for me.
Comment 18 Wan-Teh Chang 2003-05-19 11:38:36 PDT
We need to research this problem more to know if Kai's fix
is correct.  The key issue is whether it is legal for a
CERTName structure to contain a null 'rdns' pointer.  If it
is legal, then CERT_CopyName should check for a null from->rdns
and return SECSuccess.  If it is not legal, then Kai's patch
is correct, but we'll need to find out why from->rdns is null
because it is either caused by some problem with the cert or
a bug in a higher-level NSS function (the latter we should track
down and fix).

If you know why from->rdns is null, please let us know.  Thanks.
Comment 19 Wan-Teh Chang 2003-05-20 17:28:18 PDT
Created attachment 123840 [details] [diff] [review]
Alternate patch v1

This is a different way to fix the crash.  The only
difference from Kai's patch is that it returns success
if from->rdns is null.	If we are pressed for time,
we should check in either Kai's patch or this patch
right away for Mozilla 1.4 final, and investigate why
from->rdns is null later.

I also found that the email message does not crash
AOL Communicator.
Comment 20 Nelson Bolyard (seldom reads bugmail) 2003-05-20 21:29:28 PDT
Comment on attachment 123696 [details] [diff] [review]
Patch v1

That patch doesn't call PORT_SetError before returning SECFailure.  

I have debugged this, and have a much larger patch forthcoming.
Comment 21 Nelson Bolyard (seldom reads bugmail) 2003-05-20 23:07:53 PDT
The value from->rdns is NULL because of bug 174885.  This bug is another 
manifestation of that bug.  I have attached a patch to that bug that corrects
that problem, and will make from->rdns be non-NULL in this scenario.  

The stack trace shown above in comment 15 only occurs if keepcerts (the last
argument to NSS_CMSSignedData_ImportCerts) is non-zero, which may explain why 
some clients experience this crash and others do not.  I had to change my 
copy of cmsutil to set this to 1 to reproduce that stack trace.

The crash occurs because a CA cert in the chain has an unusual, perhaps 
improper, nameConstraints extension.  While attempting to reproduce this crash,
I found other crashes also in the handling of NameConstraints.  I will attach
a patch to this bug that corrects these crashes.  These patches prevent the
crash, but I am not certain that they cause the unusual nameConstraints
extension to be handled properly.  With the crash eliminated, the signing 
cert is found to be invalid because the nameConstraints test fails.
Comment 22 Nelson Bolyard (seldom reads bugmail) 2003-05-20 23:11:55 PDT
Created attachment 123863 [details] [diff] [review]
patch v2

This patch sets the error code before returning SECFailure in CERT_NameCopy.
It also initializes an arena pointer that previous was left NULL, and does NOT
attempt to free memory allocated from an arena when the parsing of a Name
constraints extension fails.
Comment 23 Nelson Bolyard (seldom reads bugmail) 2003-05-20 23:25:28 PDT
Here is the unusual name constraints extension as shown by "dumpasn1" 

 763 30  258:         SEQUENCE {
 767 06    3:           OBJECT IDENTIFIER nameConstraints (2 5 29 30)
            :             (X.509 id-ce (2 5 29))
 772 01    1:           BOOLEAN TRUE
 775 04  247:           OCTET STRING, encapsulates {
 778 30  244:               SEQUENCE {
 781 A0  241:                 [0] {
 784 30   38:                   SEQUENCE {
 786 A0   36:                     [0] {
 788 06   10:                       OBJECT IDENTIFIER '1 3 6 1 4 1 311 20 2 3'
 800 A0   22:                       [0] {
 802 0C   20:                         UTF8String '.ntdev.microsoft.com'        
                
            :                         }
            :                       }
            :                     }
 824 30   38:                   SEQUENCE {
 826 A0   36:                     [0] {
 828 06   10:                       OBJECT IDENTIFIER '1 3 6 1 4 1 311 20 2 3'
 840 A0   22:                       [0] {
 842 0C   20:                         UTF8String '.ntdev.microsoft.com'
            :                         }
            :                       }
            :                     }
 864 30   43:                   SEQUENCE {
 866 A0   41:                     [0] {
 868 06   10:                       OBJECT IDENTIFIER '1 3 6 1 4 1 311 20 2 3'
 880 A0   27:                       [0] {
 882 0C   25:                         UTF8String '.ntdev.corp.microsoft.com'
            :                         }
            :                       }
            :                     }
 909 30   43:                   SEQUENCE {
 911 A0   41:                     [0] {
 913 06   10:                       OBJECT IDENTIFIER '1 3 6 1 4 1 311 20 2 3'
 925 A0   27:                       [0] {
 927 0C   25:                         UTF8String '.ntdev.corp.microsoft.com'
            :                         }
            :                       }
            :                     }
 954 30    2:                   SEQUENCE {
 956 81    0:                     [1] Error: Object has zero length.
            :                     }
 958 30   22:                   SEQUENCE {
 960 82   20:                     [2] '.ntdev.microsoft.com'
            :                     }
 982 30   27:                   SEQUENCE {
 984 82   25:                     [2] '.ntdev.corp.microsoft.com'
            :                     }
1011 30    4:                   SEQUENCE {
1013 A4    2:                     [4] {
1015 30    0:                       SEQUENCE {}
            :                       }
            :                     }
1017 30    2:                   SEQUENCE {
1019 86    0:                     [6] Error: Object has zero length.
            :                     }
1021 30    2:                   SEQUENCE {
1023 87    0:                     [7] Error: Object has zero length.
            :                     }
            :                   }
            :                 }
            :               }
            :           }
Comment 24 Nelson Bolyard (seldom reads bugmail) 2003-05-20 23:44:05 PDT
Created attachment 123866 [details]
CA cert with unusual extension (base64 encoded)

Questions: 
1. should a zero-length GeneralName in the name constraints extension 
   be treated as if it is not present?	
2. Should an empty directory Name be treated as if it is not present?

RFC 3280 does not suggest this that I can see.
Comment 25 Nelson Bolyard (seldom reads bugmail) 2003-05-21 20:49:58 PDT
Created attachment 123960 [details] [diff] [review]
patch v3. quite different from v1 and v2

This patch incorportates wtc's review comments.  
It completely removes from cert_DecodeNameConstraintSubTree() the erroneous
code for freeing decoded name constraints that were allocated from an
arenapool.   
CERT_CopyName now produces a new CERTName that is an exact replica of the one
passed as a "from" argument, whether from->rdns is NULL or not.  This frees
CERT_CopyName from having to make a judgement on the validity of the name.

I believe mozilla 1.4 should take this patch AND the patch to bug 174885.
Together, these patches correct the parsing and copying of cert distinguished
names.	all.sh (regression test script) passes with these patches in place.
Comment 26 Nelson Bolyard (seldom reads bugmail) 2003-05-21 20:53:35 PDT
Comment on attachment 123960 [details] [diff] [review]
patch v3. quite different from v1 and v2

please review.
Comment 27 Wan-Teh Chang 2003-05-21 21:08:53 PDT
Comment on attachment 123960 [details] [diff] [review]
patch v3. quite different from v1 and v2

r=wtc.	Thanks, Nelson.
Comment 28 Wan-Teh Chang 2003-05-21 21:22:19 PDT
Comment on attachment 123960 [details] [diff] [review]
patch v3. quite different from v1 and v2

Requesting mozilla 1.4 approval.  This crash is a mozilla 1.4 blocker.
The risk of this patch is low.
Comment 29 (not reading, please use seth@sspitzer.org instead) 2003-05-21 23:36:47 PDT
Comment on attachment 123960 [details] [diff] [review]
patch v3. quite different from v1 and v2

a=sspitzer
Comment 30 Kai Engert (:kaie) 2003-05-22 21:32:06 PDT
Nelson or Wan-Teh, will you move the NSS_CLIENT_TAG to land this fix? (Note that
we have not yet created a 1.4 branch).
Comment 31 Nelson Bolyard (seldom reads bugmail) 2003-05-23 23:29:13 PDT
Above patch checked in on NSS trunk.

/cvsroot/mozilla/security/nss/lib/certdb/genname.c,v  <--  genname.c
new revision: 1.9; previous revision: 1.8

/cvsroot/mozilla/security/nss/lib/certdb/secname.c,v  <--  secname.c
new revision: 1.11; previous revision: 1.10

additional patches to genname.c and secname.c forthcoming.
Comment 32 Nelson Bolyard (seldom reads bugmail) 2003-05-24 00:11:19 PDT
Checked in on NSS 3.8 branch.

/cvsroot/mozilla/security/nss/lib/certdb/genname.c,v  <--  genname.c
new revision: 1.8.34.1; previous revision: 1.8

/cvsroot/mozilla/security/nss/lib/certdb/secname.c,v  <--  secname.c
new revision: 1.9.34.1; previous revision: 1.9
Comment 33 Nelson Bolyard (seldom reads bugmail) 2003-05-24 00:28:01 PDT
Created attachment 124121 [details] [diff] [review]
Additional patch to nss/lib/certdb/secname.c

This patch supplements the fixes in v3 above for genname.c.  Low risk, IMO.
Comment 34 Jeffrey Altman 2003-05-25 20:07:14 PDT
I can confirm that build 2003052508 no longer crashes when reading e-mails
signed with the Microsoft Research CA issued certificates.

Comment 35 Wan-Teh Chang 2003-05-27 17:23:14 PDT
Comment on attachment 124121 [details] [diff] [review]
Additional patch to nss/lib/certdb/secname.c

r=wtc.

Requesting mozilla 1.4 approval.  This is a low risk patch that tests
for null pointers to prevent crashes.
Comment 36 Wan-Teh Chang 2003-05-27 17:38:33 PDT
Comment on attachment 123960 [details] [diff] [review]
patch v3. quite different from v1 and v2

I checked in this patch on the MOZILLA_1_4_BRANCH for
the mozilla 1.4 final release.
Comment 37 Nelson Bolyard (seldom reads bugmail) 2003-05-28 00:51:18 PDT
Created attachment 124342 [details] [diff] [review]
Additional patch to nss/lib/certdb/genname.c

This patch eliminates other potential crashes in code related to certificate 
names.	This is a context diff, due to the percentage of changed lines in the
affected functions.  This patch eliminates crashes only, and does not alter 
the logic used to determine if the names actually meet the constraints, or not.

Issues with the correctness of the constraint matching logic will be the
subject
of another bug.
Comment 38 Randell Jesup [:jesup] 2003-05-28 08:35:12 PDT
wtc: PLEASE use diff -u.  I can't reasonably read your patch.
Comment 39 Asa Dotzler [:asa] 2003-05-28 08:40:44 PDT
Comment on attachment 124121 [details] [diff] [review]
Additional patch to nss/lib/certdb/secname.c

a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Comment 40 Randell Jesup [:jesup] 2003-05-28 08:43:29 PDT
wtc: Please repost the patch with -u for review/approval
Comment 41 Wan-Teh Chang 2003-05-29 08:04:52 PDT
Comment on attachment 124121 [details] [diff] [review]
Additional patch to nss/lib/certdb/secname.c

This patch has been checked into MOZILLA_1_4_BRANCH (mozilla 1.4
final), NSS_CLIENT_TAG (mozilla 1.5a), and NSS_3_8_BRANCH (NSS 3.8.1).
Comment 42 Randell Jesup [:jesup] 2003-05-29 08:50:20 PDT
I'm sorry.  Nelson, please resubmit the patch with diff -u so we can read it.
Comment 43 Nelson Bolyard (seldom reads bugmail) 2003-05-29 14:55:30 PDT
Since all of the patches except one have been obsoleted or checked in, I
gather that "the" patch to which you're referring is the "Additional patch to
nss/lib/certdb/genname.c".  That patch is a complete rewrite of two functions.
The conext diff shows all the old code, which was replaced in its entirety,
and all the new code.  If you want to review the new code, just read the second
half of the patch.  A unified diff would be meaningless.  I emailed you a
unified diff to make this point.
Comment 44 Samir Gehani 2003-05-30 11:41:42 PDT
adt: nsbeta1+/adt3
Comment 45 Wan-Teh Chang 2003-05-30 14:15:29 PDT
Comment on attachment 124342 [details] [diff] [review]
Additional patch to nss/lib/certdb/genname.c

r=wtc.

Requesting mozilla 1.4 approval.  This patch fixes a lot of
potential crashes due to dereferencing null pointers or stepping
beyond the end of strings.  This is a big patch, but the changes
can be summarized as "always testing for memory allocation
failures and always testing for the end of strings".
Comment 46 Asa Dotzler [:asa] 2003-06-01 01:44:18 PDT
Comment on attachment 124342 [details] [diff] [review]
Additional patch to nss/lib/certdb/genname.c

a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Comment 47 Kai Engert (:kaie) 2003-06-01 23:49:34 PDT
Let me know if you don't have a 1.4 branch checked out and want me to help with
checking it in.
Comment 48 Rafael Ebron (:rebron) 2003-06-02 10:49:19 PDT
a=adt
Comment 49 Wan-Teh Chang 2003-06-02 11:17:23 PDT
All three patches in this bug have been checked in on the
NSS tip (NSS 3.9), NSS_3_8_BRANCH (NSS 3.8.1), NSS_CLIENT_TAG
(Mozilla 1.5 alpha), and MOZILLA_1_4_BRANCH (Mozilla 1.4 final).
Comment 50 Nelson Bolyard (seldom reads bugmail) 2003-06-02 17:08:03 PDT
The above patches are believed to eliminate crashes that can be caused by 
external input (e.g. by received certificates).  There remain other issues
with genname.c (other crashes, incorrect name constraint processing). Per
Wan-Teh's request, I will file additional bugs about these and mark them as
depending on this bug, rather than reopening this bug.
Comment 51 Wan-Teh Chang 2003-06-05 15:50:00 PDT
Patches checked into NSS_3_7_BRANCH for NSS 3.7.7 Beta 1.
Comment 52 Wan-Teh Chang 2003-06-20 16:59:13 PDT
Patches checked in on the NSS_3_4_BRANCH (3.4.4).

Note You need to log in before you can comment on or make changes to this bug.