Re: IMAIL (Ipswitch) DoS with Eudora (Qualcomm)

[anthony () SANTEN NET (Anthony Santen)]

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