[14488] in bugtraq
Re: IMAIL (Ipswitch) DoS with Eudora (Qualcomm)
daemon@ATHENA.MIT.EDU (Anthony Santen)
Mon Apr 10 13:35:19 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <03c801bfa05c$55dac7e0$0200a8c0@ch.kookiejar.net>
Date: Fri, 7 Apr 2000 02:23:13 -0400
Reply-To: Anthony Santen <anthony@SANTEN.NET>
From: Anthony Santen <anthony@SANTEN.NET>
X-To: Jeff Beckley <beckley@qualcomm.com>
To: BUGTRAQ@SECURITYFOCUS.COM
Jeff,
Thank you.
I was aware of the Qualcomm fix (which I should therefore have included in
my original submission) however.
The main issue, in this case, is not the fact that there seems to be a
conflict during authentication.
The main issue is that anyone can close down an IMAIL server AT WILL.
IMAIL must protect itself from this at a SERVER level.
best regards
Anthony Santen
----- Original Message -----
From: "Jeff Beckley" <beckley@qualcomm.com>
To: "Anthony Santen" <anthony@santen.net>
Cc: <BUGTRAQ@securityfocus.com>
Sent: Thursday, April 06, 2000 8:08 PM
Subject: Re: IMAIL (Ipswitch) DoS with Eudora (Qualcomm)
> 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
>
>
