(Vendor Releases Fix) Re: RitLab's The Bat! E-Mail Client Allows a User's E-Mail to Be Made Unretrievable When Downloading a Specifically Formatted E-Mail Message
SecurityTracker Alert ID: 1001415|
SecurityTracker URL: http://securitytracker.com/id/1001415
(Links to External Site)
Date: Apr 24 2001
Denial of service via network|
Fix Available: Yes Vendor Confirmed: Yes |
SECURITY.NNOV reports that there is a vulnerability in The Bat! e-mail client that allows a remote user to send mail to a vulnerable e-mail client causing the client to be unable to retrieve further messages when the e-mail is retrieved.|
While RETRiving messages via the POP3 e-mail protocol, The Bat! incorrectly processes the 0x0D (Carriage Return) character if it is not followed immediately by a 0x0A (Line Feed) character. The Bat! reportedly incorrectly interprets this event as the end of the message and the remaineder of the message is incorrectly interpreted as a reply from the POP3 e-mail server. As a result, The Bat! fails to receive the rest of the messages in the user's mailbox and will not delete received messages from the mail server.
Futhermore, malformed message could emulate any POP3 server replies, causing the potential for mischief.
A demonstration exploit is contained in the source message.
The vendor has reportedly been notified.
A remote user can send mail to a vulnerable e-mail client causing the client to be unable to retrieve further messages when the e-mail is retrieved.|
The vendor reports that The Bat! v1.42 Beta/10, released Sat, 21 Apr 2001, fixes CR handling. The vendor adds that "It is now strict to line endings. Only <CR><LF>.<CR><LF> is now treated as end of message." See the source message for details.|
Vendor URL: www.ritlabs.com/ (Links to External Site)
Exception handling error|
|Underlying OS: Windows (Me), Windows (NT), Windows (95), Windows (98), Windows (2000)|
This archive entry is a follow-up to the message listed below.|
Source Message Contents
Subject: Re: SECURITY.NNOV: The Bat! <cr> bug|
The Bat! v1.42 Beta/10 released Sat, 21 Apr 2001 fixes CR handling
that you've described. It is now strict to line endings. Only
<CR><LF>.<CR><LF> is now treated as end of message.
Mon, 23 Apr 2001 12:46:23 +0400, you wrote:
mfb>> This is not a bug of The Bat! but a bug of MTA (POP3/SMTP servers)
mfb>> that allow such odd messages. The proposed "bad-message"
mfb>> (http://www.security.nnov.ru/files/badmess.zip) is not
mfb>> RFC-compliant. Any RFC-compliant POP3/SMTP server must either bounce
mfb>> or cure it. I've used a proposed example to send the message to
mfb>> myself, on a FreeBSD server with Sendmail 8.11.1 I've typed
mfb>> cat badmess | sendmail -U email@example.com
3> You're wrong. This message _is_ RFC 822 and RFC 1251 compliant. In
3> fact, RFC 822 absolutely clear allows <CR> and <LF> even in some
3> message headers:
3> text = <any CHAR, including bare ; => atoms, specials,
3> CR & bare LF, but NOT ; comments and
3> including CRLF> ; quoted-strings are
3> ; NOT recognized.
3> _any_ pop3 server shouldn't change this message, because RFC 1939
3> follows RFC 822 for message standard.
3> RFC 821 (SMTP) simply says "The mail data may contain any of the 128
3> ASCII character codes".
3> RFC 1251 allow message to contains any binary data and strings of any
3> length. In fact, sendmail allows any characters (including NULL) to be
3> in message body. "badmess" was tested with sendmail 8.9.3 + mail.local
3> + UW-pop3d 7.59.
3> P.S. I didn't tested The Bat! with NULL characters in message body...
3> If something like
3> in message body hurts The Bat! badly RitLabs better patch it right now
Vice President, Ritlabs S.R.L.