319210 - crash [@ plc4.dll + (00001ae2)] on mail send (using SSL w/ sspi connection to SMTP)

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Andrew Jakabovics]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Thunderbird version 1.5 (20051025)

Talkback ID:  TB12392253W
Stack trace:
encode3to4  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/nsprpub/lib/libc/src/base64.c, line 58]
nsSmtpProtocol::`vftable'
nsSmtpProtocol::AddRef  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp, line 225]
0x558b0c4d


TBird 1.07 works fine. 1.5 and 1.6a both crash.


Reproducible: Always

Steps to Reproduce:
To reproduce bug:
1. Run Thunderbird
2. compose mail
3. send

Actual Results:  
it crashes before getting to prompt for mail server password


Expected Results:  
outgoing mail server password dialog box pops up; then mail gets sent

Similar to bug 217065, but crash seems to be in module plc4.dll, not fullsoft.dll.

I've gotten this a number of times. It's always repeatable. Here are the Talkback IDs:
TB12635168K 
TB12627467Z 
TB12392280Z
TB12392253W
TB12391552H

Comment 1

[Wayne Mery (:wsmwk)]

Andrew, 

what do you get with very recent trunk build?
If you can repeat, can you create a SMTP log as described under
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#smtp

Comment 2

[Andrew Jakabovics]

I just downloaded TB1.5 and still get the problem. Here's the SMTP log:
0[284b40]: SMTP Connecting to: outgoing.mit.edu
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 220 MIT.EDU ESMTP Snedmail (Iroquois for mailer) at Thu, 12 Jan 2006 11:48:45 -0500 (EST)
0[284b40]: SMTP entering state: 15
0[284b40]: SMTP Send: EHLO [18.174.0.100]

0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250-outgoing.mit.edu Hello CRE-VISITOR1.MIT.EDU [18.174.0.100], pleased to meet you
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250-ENHANCEDSTATUSCODES
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250-PIPELINING
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250-8BITMIME
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250-SIZE 31457280
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250-DSN
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250-ETRN
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250-AUTH GSSAPI LOGIN
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250-DELIVERBY
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 250 HELP
0[284b40]: SMTP entering state: 4
0[284b40]: SMTP entering state: 22
0[284b40]: SMTP entering state: 24
0[284b40]: SMTP Send: AUTH GSSAPI YIIB7wYJKoZIhvcSAQICAQBuggHeMIIB2qADAgEFoQMCAQ6iBwMFACAAAACjggESYYIBDjCCAQqgAwIBBaEQGw5BVEhFTkEuTUlULkVEVaIjMCGgAwIBAqEaMBgbBHNtdHAbEG91dGdvaW5nLm1pdC5lZHWjgcswgcigAwIBAaEDAgEDooG7BIG43TnHCgCbMxU0gDyJ1+uwHIw4yQu3aDUs4mvQSpJDz4kZnaCGLYiQPWIKlfvcbvJsh313ih41C9zd7U0D3nGlk9pnpXFA907l3No6kw/21DFb25YOBA5VwPqovggL1k+hGpMshaX+YxhpTN5V817FTRCJsEmpTS2s61X6hsm0R7iCmV2/KCcwvFFBHmg/nJe0vN5kXfM0bTKdslMZKS7OetZb9hO6mnUWbF24osFLjlgwjlwS6mfkaKSBrjCBq6ADAgEBooGjBIGgd91Umm2lBkVINI2xIUMaZ9M4
0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 334 YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMCAQGiQgRANMCR85Xu/Q4YlWDj6RRk5BEHUWcDZVt/NSqKHUNcr/zChQi8bd5QS+0iSz+l9+2qVH5Hwi7ZW6wIh6iszAYS7Q==
0[284b40]: SMTP entering state: 25
0[284b40]: SMTP Send: 

0[284b40]: SMTP entering state: 0
0[284b40]: SMTP Response: 334 YDMGCSqGSIb3EgECAgIBAAD/////AnZyFbH/FdvNE70gl7YAUqWYgi36yXjgBwAgAAQEBAQ=
0[284b40]: SMTP entering state: 25

Comment 3

[Mike M.]

(In reply to comment #2)

This actually looks like it could be a kerberos problem.  It looks like SMTP is trying to authenticate via kerberos and that's where the crash is happening.  This seems to only happen on Windows PCs at MIT that are on the Win Athena domain.  I'm not sure if it can be replicated elsewhere.  It works fine on my home PC even with MIT's kerberos sw running (that machine isn't logged into the MIT Win Athena domain however), it may just be a problem with kerberos in the domain itself.  I have no way to debug it unfortunately.  Also, it only happens when username+password+ssl are on.

Comment 4

[Simon Wilkinson]

Are you intentionally using Kerberos on this machine?

Is it a member of an Active Directory realm?

Hhave you got MIT's Kerberos for Windows installed? And if so, have you got valid credentials in Kerberos for Windows?

Comment 5

[Andrew Jakabovics]

I don't think it's part of an Active Directory realm.
Kerberos runs automatically at startup and my user authentication to the network is via kerberos. My WinAthena login gives me kerberos 4 and 5 tickets.

Comment 6

[Mike M.]

(In reply to comment #4)

I don't know about Active Directory; I'm not sure how they setup the domain...

However, I do know that I am using Kerberos for Windows and have valid credentials, KFW is required to be able to login to the Win Athena domain and use AFS and all our printers, etc.

The other thing is that I can use KFW at home (without being logged into the Win Athena domain) and Thunderbird works fine; I tested this by running the Leash client and then trying to send mail via ssl+user+pw.  I think it may be something that's part of being in the Win Athena domain that's causing the problem but I don't know what.

-mm

Comment 7

[Simon Wilkinson]

What I'm interested in is whether you're using SSPI, or a GSSAPI library to do Kerberos from Thunderbird. Whilst the Thunderbird interface to the GSSAPI library is very well tested, as the code is used on all platforms, SSPI is Windows specific, and hasn't been tested as much.

You can check this by launching the Config Editor (go to Tools->Options->Advanced, and click the 'Config Editor' button). Let me know what the value of the network.auth.use-sspi variable is ...

32315 looks like its a dup of this bug, too - and there's a fair number of talkback IDs with this stack profile. I think we're doing something which is causing a bad string to be passed to the base64 encoding routines. My suspicion is that this is SSPI specific, which limits the amount I can investigate this.

Comment 8

[Mike M.]

(In reply to comment #7)

Hi,

network.auth.use-sspi is set to true for me.

Comment 9

[Mike M.]

(In reply to comment #8)

Wow!  I turned off network.auth.use-sspi it worked!

I get no crash now with ssl+username+pw with that off.

Comment 10

[Andrew Jakabovics]

(In reply to comment #9)
> (In reply to comment #8)
> 
> Wow!  I turned off network.auth.use-sspi it worked!
> 
> I get no crash now with ssl+username+pw with that off.
> 

Same here. :)

Comment 11

[Simon Wilkinson]

The SSPI code is broken. The Wrap method never sets 'outTokenLen', so it doesn't return a correct length to the server.

Also, it returns the Windows SECURITY_STATUS return code to the caller as a NS_RESULT. Is this really safe?

Patch fixing both of these to follow ...

Comment 12

[Simon Wilkinson]

Attachment: Fixes problem with Wrap() not setting output length, and with dubious return codes

Patch is trivial, and fixes a crash in Thunderbird 1.5 which will be encountered when ever users try to use native Windows Kerberos for authentication. Can it be considered for inclusion in 1.5.0.1?

Comment 13

[Simon Wilkinson]

cneberg, could you take a look at the attached patch, and see if it makes sense to you?

Comment 14

[Christopher Nebergall]

diff -u -r1.6 nsAuthSSPI.cpp
--- nsAuthSSPI.cpp	4 Jan 2006 16:23:10 -0000	1.6
+++ nsAuthSSPI.cpp	23 Jan 2006 18:41:13 -0000
@@ -413,7 +413,10 @@
 
     nsMemory::Free(ib[0].pvBuffer);
 
-    return rc;
+    if (rc != SEC_E_OK) 
+        return NS_ERROR_UNEXPECTED;

Could you change this to if (rc != SEC_SUCCESS(rc)) to match the other checks?
Also, could you use NS_ERROR_FAILURE rather than NS_ERROR_UNEXPECTED for both of your changes in the patch?  This will make its return values in similiar situations the same for the GSS and the SSPI implementations.

@@ -508,7 +511,11 @@
 
         memcpy(outToken + bufs.ib[0].cbBuffer + bufs.ib[1].cbBuffer,
                bufs.ib[2].pvBuffer, bufs.ib[2].cbBuffer);
+
+        outTokenLen = len;

*outTokenLen = len, No?
 
Also, I know this was my code but I noticed a I missed an out of memory check in  unwrap.  If you don't want to mess with this I'll create another bug.

Example addition.
 
    ib[0].pvBuffer = nsMemory::Alloc(ib[0].cbBuffer);

+if (!ib[0].pvBuffer)
+  return NS_ERROR_OUT_OF_MEMORY;

    memcpy(ib[0].pvBuffer, inToken, inTokenLen);

Thanks!

Comment 15

[Darin Fisher]

Comment on attachment 209370 [details] [diff] [review]
Fixes problem with Wrap() not setting output length, and with dubious return codes

>Index: nsAuthSSPI.cpp

>+        outTokenLen = len;
>+        
>+        return NS_OK;

Don't you mean "*outTokenLen = len" ?

Comment 16

[Darin Fisher]

Comment on attachment 209370 [details] [diff] [review]
Fixes problem with Wrap() not setting output length, and with dubious return codes

Oh, I didn't see cneberg's comments.  Please post a new patch, and request review from him.

Comment 17

[Simon Wilkinson]

Attachment: Better fix

cneberg, could you take a look at this new patch. It fixes the stupid outputLen typo; alters the return code checks to use SEC_SUCCESS, and return NS_ERROR_FAILURE; and adds in an out of memory return for the only unchecked use of Alloc() that I could find.

Comment 18

[Christopher Nebergall]

Comment on attachment 209512 [details] [diff] [review]
Better fix

Looks good.  r=cneberg

Comment 19

[David :Bienvenu]

fix checked in.

Comment 20

[Scott MacGregor]

Comment on attachment 209512 [details] [diff] [review]
Better fix

I don't see any benefit in baking this particular change on the trunk. So approving for thunderbird 2.

nominating for 1.8.0.2. 

Would be great if you guys could help verify the fix.

Comment 21

[Simon Wilkinson]

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

Comment 22

[Scott MacGregor]

approving for the next thunderbird update as this is showing up in talkback.

Comment 23

[Marcia Knous [:marcia]]

Andrew: QA would like to verify that this bug is fixed in Tbird version 1.5.0.2 (20060308) build.  Can you please verify that the problem no longer exists in that build? Thanks.

Comment 24

[Andrew Jakabovics]

It works now, even with network.auth.use-sspi set to the default value (true).
Thanks for all your help on this.
-andrew

Comment 25

[Tracy Walker [:tracy]]

verified per comment #24, thanks Andrew

Comment 26

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.3 using talkback data