139329 - Mozilla repeatedly crashes when sending mail with a personal certificate

Status: VERIFIED FIXED

(MailNews Core :: Security: S/MIME, defect, P1)

Description

[Philip White]

Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0rc1) Gecko/20020417

I got a personal certificate from Thawte.  It installed into Mozilla with no
problems, and I was able to select it in Mail preferences.
I have chosen to sign my mail by default.

When I try to mail someone from that account, Mozilla crashes entirely as soon
as I hit the "Send" icon.  This happened twice in a row, at exactly the same
point.  I've filed a talkback report, but I triggered another crash which closed
the report window before I jotted down the number.  I realize how unhelpful that
sounds.

You may combine this with bug 139095, which is another one I reported about my
Mozilla.  I don't know, maybe it's a bad installation.

I searched for duplicates to this bug, but none seemed the same as this one. 
Nevertheless, I'll set it to unconfirmed rather than new, in case it's a dupe.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

->PSM

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Reassigning

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Hmm, auto-reassigning didn't work. Manually reassigning to ssaux.

Comment 4

[Adrian Tritschler]

This happens repeatably with release candidate one on a Windows XP workstation.

The certificate was issued by our University.

In the Mail and newsgroup account properties -> Security -> Digital Signing, it
was set to "Yes" and the certificate had been selected.

On composing a new message, clicking on "Security" showed 'DIgitally signed: not
possible" and "Encrypted: no", on hitting "send" mozilla crashes.

The only workaround I found is to disable digital signing in the mail and
newsgroup properties.

Comment 5

[Charles Rosendahl]

Question:

have you configured both the signing and encryption options in the settings, or
just the signing option?  If just the signing option, try configuring both and
let me know the result.

Also, what is the key size in your certificate - 512, 1024, or 2048?

Also, what are the talkback id numbers, if you know?

Comment 6

[Charles Rosendahl]

Talkback ID 5494722

Appears to be a different fault:

Stack Signature  nsslibc_memequal() 8919249b
Email Address [e-mail]
Product ID Mozilla1.0
Build ID 2002041711
Trigger Time 2002-04-22 15:56:46
Platform LinuxIntel
Operating System Linux 2.4.18-6mdk
Module libnss3.so
URL visited
User Comments I added a personal certificate, configured Mail client to use it,
then tried sending a message to my other account. As soon as I hit "Send", it
crashed.
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)

Stack Trace
nsslibc_memequal()
nssUTF8_Equal()
match_nickname()
nss_hash_enumerator()
PL_HashTableEnumerateEntries()
nssHash_Iterate()
nssCertificateStore_FindCertificatesByNickname()
NSSCryptoContext_FindBestCertificateByNickname()
CERT_FindCertByNickname()
CERT_FindUserCertByUsage()
nsNSSCertificateDB::GetEmailEncryptionCert()
nsMsgComposeSecure::MimeCryptoHackCerts()
nsMsgComposeSecure::BeginCryptoEncapsulation()
nsMsgComposeAndSend::BeginCryptoEncapsulation()
nsMsgSendPart::Write()
nsMsgComposeAndSend::GatherMimeAttachments()
nsMsgComposeAndSend::HackAttachments()
nsMsgComposeAndSend::Init()
nsMsgComposeAndSend::CreateAndSendMessage()
_SendMsg__12nsMsgComposeiP14nsIMsgIdentityi()
nsMsgCompose::SendMsg()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
nsXPCWrappedJSClass::CallMethod()
nsXPCWrappedJS::CallMethod()
PrepareAndDispatch()
nsXPTCStubBase::Stub5()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
nsXULElement::HandleDOMEvent()
PresShell::HandleDOMEventWithTarget()
nsButtonBoxFrame::MouseClicked()
nsButtonBoxFrame::HandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEventWithTarget()
nsEventStateManager::CheckForAndDispatchClick()
nsEventStateManager::PostHandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsViewManager::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::DispatchMouseEvent()
nsWidget::OnButtonReleaseSignal()
nsWindow::HandleGDKEvent()
dispatch_superwin_event()
handle_gdk_event()

Comment 7

[Stephane Saux]

kai.
cc relyea

Reporter: can you confirm that your encryption cert pref is set as well?

Comment 8

[Philip White]

I have installed the certificate and configured mail preferences to digitally 
sign outgoing mail with that certificate by default.
As soon as I unchecked the checkbox to sign mail by default, it all works fine. 
(Doesn't sign my mails, though, obviously. :))

Comment 9

[Philip White]

The key size that I've chosen is 2048, and Thawte site seemed to allow Mozilla 
to generate the key, because I saw a standard Mozilla dialog box that was 
generating the key.

I will try setting the Encrypt option when I get home and let you know.

Comment 10

[Philip White]

I have selected the same certificate both for signing and for encrypting.  In
the encryption part, I selected the "Never" radio button.  Looking at the
Security button's "Message Security" option of the Compose window, the mail will
be signed but not encrypted.
This time it sent the mail without a glitch.

Changing encryption status to "Required" now says that encryption to my other
account is not possible, presumably because it doesn't know the certificate for
that account.  No crash and no problems.

Apparently, the only time a serious problem occurs is when all of these
conditions are true:
1) there is a certificate selected for digital signing
2) the mail account is configured to digitally sign messages by default
3) no certificate is selected for the encryption part (radio boxes in that part
are ghosted)

Comment 11

[Kai Engert (:KaiE:)]

I'm unable to reproduce the crash.

When I prepare my profile like you described it in your previous comment, I see
the following message:
"... failed to find encryption certto include in the signed message...".

Can you please try whether your cert database is corrupted?
Can you backup your cert using cert manager to a p12 file, quit Mozilla, go to
you profile directory, move all *.db files to a backup location, restart
Mozilla, use cert manager to import your own p12 file, and try again? Does it
still crash?

If yes, I'm curious, can you look at your profile's prefs.js file, and look
whether what the settings for
  user_pref("mail.identity.id1.encryption_cert_name", "");
  user_pref("mail.identity.id1.encryptionpolicy", 0);
are? Are they identical to those strings? (Besides having a different string for
id1 maybe.)

Comment 12

[Charles Rosendahl]

With the latest builds, I too can not crash.  I see the error messages - this is 
true on Mac, Linux, and Win32.

Comment 13

[[e-mail] (gone - use [e-mail] instead)]

I see the crash on Windows 2000 - with branch build 2002-05-01-06.

The certificate was on obtained from our internal security server.

From prefs.js:

user_pref("mail.identity.id2.encryption_cert_name", "");
user_pref("mail.identity.id2.encryptionpolicy", 0);

Comment 14

[[e-mail] (gone - use [e-mail] instead)]

Here's my stack info (as pitiful as it is):

Build ID  2002050108
Trigger Time 2002-05-01 13:58:18
Platform Win32
Operating System Windows NT 5.0 build 2195
Module nss3.dll
URL visited .
User Comments Crashed, digitally signing a message with a certificate.
Trigger Reason Access violation
Source File Name
Trigger Line No.
Stack Trace
nss3.dll + 0x33b0e (0x060b3b0e) 

Comment 15

[Charles Rosendahl]

Was that Trunk or Branch?  Also, after the crash, can you restart the browser
and attempt to send a message again?  Hopefully you won't crash, but instead
will see a configuration error message.

Comment 16

[[e-mail] (gone - use [e-mail] instead)]

Mozilla1.0.0 commercial branch - yes, after crashing, and restart, I now get the
same error everybody else sees...

Comment 17

[Kai Engert (:KaiE:)]

It is bad to hear that it is a one time crash, because it makes it hard to
reproduce. Apparently, once you ran into the works, it works afterwards.


But I'm happy that I ran into another crash, and changes are high I it is the
same crash.


The crash happens sometimes when calling CERT_FindUserCeryByUsage with a zero
length nickname argument.

We arrive in function match_nickname (pkistore.c), where nickname is NULL, going
to nssUTF8_Equal, calling nsslibc_memequal with a NULL argument as first param.


#0  0x406cc8f2 in memcmp () from /lib/i686/libc.so.6
No locals.
#1  0x44aa1818 in match_nickname (k=0x0, v=0xbfff8e18, a=0x1) at pkistore.c:411
	CVS_ID = "@(#) $RCSfile: pkistore.c,v $ $Revision: 1.15.6.1 $ $Date: 2002/04/10
03:28:12 $ $Name:  $"
#2  0x44aab1b5 in nssUTF8_Equal (a=0x0, b=0xbfff8e18 "", statusOpt=0xbfff8c88)
at utf8.c:758
	la = 1
	lb = 1
#3  0x44aa187a in match_nickname (k=0x8814934, v=0x87f8060, a=0xbfff8d24) at
pkistore.c:439
	nssrv = PR_SUCCESS
	c = (NSSCertificate *) 0x88148f8
	nickname = (NSSUTF8 *) 0x0
	subjectList = (nssList *) 0x87f8060
	nt = (struct nickname_template_str *) 0xbfff8d24
#4  0x44aac1be in nss_hash_enumerator (he=0x87efd08, index=0, arg=0xbfff8d04) at
hash.c:376
	as = (struct arg_str *) 0xbfff8d04
#5  0x4030e2d1 in PL_HashTableEnumerateEntries (ht=0x86d0258, f=0x44aac188
<nss_hash_enumerator>, arg=0xbfff8d04) at
/home/kaie/100/mozilla/nsprpub/lib/ds/plhash.c:429
	he = (PLHashEntry *) 0x87efd08
	hep = (PLHashEntry **) 0x87efcd8
	i = 8
	nbuckets = 16
	rv = 1077378620
	n = 0
	todo = (PLHashEntry *) 0x0
#6  0x44aac213 in nssHash_Iterate (hash=0x8895438, fcn=0x44aa1818
<match_nickname>, closure=0xbfff8d24) at hash.c:399
	as = {fcn = 0x44aa1818 <match_nickname>, closure = 0xbfff8d24}
#7  0x44aa18e3 in nssCertificateStore_FindCertificatesByNickname
(store=0x88953f8, nickname=0xbfff8e18 "", rvOpt=0x0, maximumOpt=0, arenaOpt=0x0)
at pkistore.c:464
	rvArray = (NSSCertificate **) 0x0
	nt = {nickname = 0xbfff8e18 "", subjectList = 0x0}
#8  0x44a9cf2e in NSSCryptoContext_FindBestCertificateByNickname (cc=0x88953d8,
name=0xbfff8e18 "", timeOpt=0x0, usage=0xbfff8d9c, policiesOpt=0x0) at
cryptocontext.c:226
	i = 0
	c = (NSSCertificate *) 0x1
	nickCerts = (NSSCertificate **) 0x8880bb8
	best = {cert = 0x0, time = 0xbfff8d5c, sTime = {prTime = 1020399470449965}, usage
= 0xbfff8d9c, policies = 0x0}
#9  0x44a87455 in CERT_FindCertByNickname (handle=0x8894020, nickname=0xbfff8e18
"") at stanpcertdb.c:382
	cc = (NSSCryptoContext *) 0x88953d8
	c = (NSSCertificate *) 0x44a8741c
	ct = (NSSCertificate *) 0x0
	cert = (CERTCertificate *) 0x0
	usage = {anyUsage = 1, nss3usage = 3221196256, nss3lookingForCA = 1073796304}
#10 0x44a53aa6 in CERT_FindUserCertByUsage (handle=0x8894020,
nickname=0xbfff8e18 "", usage=certUsageEmailRecipient, validOnly=1,
proto_win=0x88db6c8) at certhigh.c:282
	cert = (CERTCertificate *) 0x0
	certList = (CERTCertList *) 0x0
	rv = 143505096
	time = 1020399470449753

Comment 18

[Kai Engert (:KaiE:)]

I now believe it is a NSS bug.
The crash depends on whether you used SSL in the session previously or not.

I'm now sure I'm seeing the same crash, because I'm able to reproduce it.


Here is how to reproduce the bug:
- select a cert for sining

- do not select a cert for encryption, if you have already configured
  a cert for encryption, quit the browser, open file prefs.js from your
  profile directory, and remove the line(s) that contain:
    encryption_cert_name

- use SSL in your session, either by accessing a page over https,
  or open your mail inbox, in case you use IMAP/SSL.
  If you have not used SSL in your session, you will not crash.

- compose a mail message to yourself. Open the dropdown box from
  the security toolbar button, and make sure signing is enabled,
  but encryption is not.

- send the message, and you'll crash.

Comment 19

[Kai Engert (:KaiE:)]

I believe this is a topcrash.

Our experience during the previous weeks has shown, many people who are trying
out S/Mime are tempted to only select the signature for signing in mail prefs.
And if you do so, seeing the crash is highly likely.

I filed NSS bug 141936.

Comment 20

[Kai Engert (:KaiE:)]

Because I think this is a topcrash, I suggest a workaround.

Because the bug only seems to occur when querying with NSS with zero lenght
string arguments, we should prevent that.

I'm attaching a simple patch that fixes the problem for me.

Comment 21

[Kai Engert (:KaiE:)]

Attachment: Suggest workaround

Comment 22

[Kai Engert (:KaiE:)]

Javi, can you please review?

Comment 23

[Javier Delgadillo]

Comment on attachment 82166 [details] [diff] [review]
Suggest workaround

r=javi

Comment 24

[Kai Engert (:KaiE:)]

Alec, can you please review this topcrash fix?

Comment 25

[Alec Flett]

Comment on attachment 82166 [details] [diff] [review]
Suggest workaround

why fix the caller, why can't we fix GetEmailEncryptionCert and
GetEmailSigningCert to check their parameters, and reset the 2nd parameter that
gets passed in?

Comment 26

[Kai Engert (:KaiE:)]

Attachment: Better workaround

Alec, your suggestion is reasonable. This is the updated patch for review.

Javi/Alec, can you please review again?

Comment 27

[Alec Flett]

Comment on attachment 82503 [details] [diff] [review]
Better workaround

looks great. sr=alecf

Comment 28

[Javier Delgadillo]

Comment on attachment 82503 [details] [diff] [review]
Better workaround

r=javi

Comment 29

[Asa Dotzler [:asa]]

Comment on attachment 82503 [details] [diff] [review]
Better workaround

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 30

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) approval for checkin to the 1.0 brnach. Pls check
this in tonight (if possible), then add the fixed1.0.0 keyword.

Comment 31

[Kai Engert (:KaiE:)]

Checked in to trunk.

Comment 32

[Kai Engert (:KaiE:)]

Checked in to 1.0.0 branch.

Comment 33

[Charles Rosendahl]

Verified using Kai's test case in comment 18

Comment 34

[Kai Engert (:KaiE:)]

*** Bug 138317 has been marked as a duplicate of this bug. ***