215742 - AUTH CRAM-MD5 authentication failure

Status: RESOLVED FIXED

(MailNews Core :: Networking: SMTP, defect)

Description

[Robert Rapplean]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.0; Windows 2000) Opera 6.05  [en]
Build Identifier: Mozilla Thunderbird 0.1 (20030723)

When attempting an authentication via CRAM-MD5, the SMTP Client fails to send an identification string.

Reproducible: Always

Steps to Reproduce:
1.Configure the client to use Name and Password authentication, under Outgoing Server settings.  Enter an appropriate user name
2.Create an email addressed to someone not at the SMTP server's domain
3.Send the email

Actual Results:  
When I attempt to use password authentication to my SMTP server, Thunderbird seems to choose CRAM-MD5 in order to accomplish this. The server responds with a 344 followed by a BASE64 encoded string of characters (as it should).  Thunderbird responds with a "3" (nothing more). TB seems to think that it's done, but the server is waiting for the rest of the string, or at least a CR-LF. The result is that both wait for the connection to time out.

This prevents me from sending any mail. I have an etherreal file available to demonstrate this. 

Expected Results:  
Mozilla should have sent a BASE-64 encoded string that consists of 
[user name][space][MD5 digest of the password]
The server would then respond with an OK response, or a failure response

I have an Ethereal capture file at http://www.rapplean.net/mail1.cap and a netscape SMTP log at http://www.rapplean.net/ns_smtp_capture.dat . The first file contains a mail sent by Netscape 7.0 with similar configuration followed an attempt at sending a message from Thunderbird.  The second is just for the thunderbird attempt.

Comment 1

[Matthias Versen [:Matti]]

The ethreal log shows AUTH login and not cram-md5 
(and please use linebreaks the next time..)

Comment 2

[Robert Rapplean]

Ethereal log shows an AUTH LOGIN performed by Netscape 7.0 (done for
comparison) followed by an attempt at CRAM-MD5 by Thunderbird.  Look
for the second EHLO rapplean.net at packet #32.

Sorry about the lack of carriage returns.  Didn't know that this interface
didn't insert them itself until it was too late.

Comment 3

[Christian Eyrich]

Robert, the server seems to be broken.

Sending the challenge with the "acofc.org" at the end is wrong. This is no legal
Base64 string.

But I nevertheless have to investigate why we're sending a "3" without CRLF
instead of recognize the decoding error and fall back to another mechanism.

Sending a message using KMail with CRAM-MD5 failed too, that's make me feel a
little bit better.

Comment 4

[Christian Eyrich]

Ok, the problem is, we detect the corrupt Base64 string but use the wrong error
handling.

Setting rv = NS_ERROR_FAILURE; in nsSmtpProtocol.cpp#1001 stops CRAM-MD5
processing and sends the uninitialized buffer which contained "3\0" in the case
Robert logged. So the server waits forever because of the lacking CRLF.

Comment 5

[Christian Eyrich]

Attachment: proposed patch

RFC 2554 says the client has to send a line with a single "*" to cancel the
authentication.
Although most servers I tested don't answer with the specified 501 but 535 or
others this should nevertheless work: we automatically fall back to the next
weaker mechanism.

At least if we remove the clear of SMTP_AUTH_CRAM_MD5_ENABLED in #1028. That
has always been wrong here because when we come back to AuthLoginResponse()
we'd clear SMTP_AUTH_LOGIN_ENABLED instead of SMTP_AUTH_CRAM_MD5_ENABLED (as it
has already been disabled in #1028) and miss our chance to use the LOGIN
mechanism.

Comment 6

[David :Bienvenu]

Comment on attachment 129770 [details] [diff] [review]
proposed patch

r=bienvenu

Comment 7

[David :Bienvenu]

request approval for 1.5 b, pending sr from mscott.

Comment 8

[Christian Eyrich]

Comment on attachment 129770 [details] [diff] [review]
proposed patch

This bug may cause the user to be unable sending mail.
The patch is simple without a real risk.

Comment 9

[Asa Dotzler [:asa]]

Comment on attachment 129770 [details] [diff] [review]
proposed patch

a=asa (on behalf of drivers) for checkin to Mozilla 1.5beta.

Comment 10

[David :Bienvenu]

fix checked in.