[14485] in bugtraq
Re: IMAIL (Ipswitch) DoS with Eudora (Qualcomm)
daemon@ATHENA.MIT.EDU (Jeff Beckley)
Thu Apr 6 21:14:29 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <4.3.1.0.20000406162649.04a2def0@adept.qualcomm.com>
Date: Thu, 6 Apr 2000 17:08:48 -0700
Reply-To: Jeff Beckley <beckley@QUALCOMM.COM>
From: Jeff Beckley <beckley@QUALCOMM.COM>
X-To: Anthony Santen <anthony@santen.net>
To: BUGTRAQ@SECURITYFOCUS.COM
I'm the lead developer for Windows Eudora here at Qualcomm, and I've been
the one who has investigated these issues of SMTP authentication with
IPSwitch's IMail server. Here's some details that may be helpful for IMail
users:
The problem is with IMail SMTP server versions 6.02 and below. When the
SMTP client gives the "AUTH CRAM-MD5" command, the IMail server returns a
challenge that is not CRLF-delimited. Thus, the SMTP client hangs waiting
for the CRLF to signal the end of the challenge. Eudora does indeed
timeout after a while.
I had some email conversations about two months ago with the Development
Manager for IMail, and he gave me a beta version of the 6.03 version of
IMail, which had the problem fixed. I'm not sure whether the 6.03 version
of IMail has been released yet or not, nor whether it is a free upgrade for
existing 6.x IMail users. I did also find that the PLAIN authentication
scheme in the 6.03 beta versions was broken. I don't know whether or not
that bug has been fixed since that time.
I created a workaround in Eudora for this bug in the 6.02 and below version
IMail servers. It is to tell Eudora not to use the CRAM-MD5 authentication
scheme, but instead use the LOGIN method, which appears to work with
IMail. Eudora 4.3 users can set that up by clicking on this URL:
<x-Eudora-option:SmtpAuthBanished=CRAM-MD5>. IPSwitch has a Knowledge Base
article on this, which can be found at
<http://support.ipswitch.com/kb/IM-20000208-DM02.htm>.
>Ipswitch blames BOTH NetScape AND Eudora for not following RFC's, but does
>nothing to control the situation.
>
>It is very simple to deny service to any IMAIL 5.xx or 6.xx server as
>follows.
>
>IMAIL allows SMTP AUTH using various methods, including CRAM-MD5 and LOGIN
>If a Eudora 4.3 client attaches to the IMAIL server supporting SMTP AUTH, it
>attempts a connection using CRAM-MD5. At this point the mail server locks
>the internal security dll (imailsec.dll) using 'Exclusive' mode, thus
>disallowing other threads to access it. The session with Eudora 4.3 will
>stay in a 'locked' state. Eudora doesn't disconnect or time-out, nor does
>Imail.
>
>While the lock is in place, NO mail client can use the server for outbound
>mail
>
>This problem has been confirmed to be only with Eudora at this time. Eudora
>4.3 has been confirmed not to show this behaviour on MS-EXCHANGE or Sendmail
>8.10.
>
>The only 'work around' available at this time is to restart the IMAIL
>services on the server.
>
>Ipswitch's 'work around' is to open the relay, disabling the SMTP AUTH in
>the process.
>
>Ipswitch denies that the problem is theirs, and claims that 'everyone else
>is mad but not us'. Several complaints regarding this problem have been
>received on the IMAIL forum.
>
>Anthony Santen
