SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (E-mail Client)  >   The Bat! Vendors:   RIT Research Labs
(Author Reiterates Vulnerability Claims) 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:  1001409
SecurityTracker URL:  http://securitytracker.com/id/1001409
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Apr 23 2001
Impact:   Denial of service via network

Version(s): 1.51
Description:   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.

The author of the original advisory reiterates the vulnerability notice and refutes the vendor's claim that the demonstration exploit message was not RFC compliant:

"This message _is_ RFC 822 and RFC 1251 compliant. In fact, RFC 822 absolutely clear allows <CR> and <LF> even in some message headers:

text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.


_any_ pop3 server shouldn't change this message, because RFC 1939 follows RFC 822 for message standard.

RFC 821 (SMTP) simply says "The mail data may contain any of the 128 ASCII character codes".

RFC 1251 allow message to contains any binary data and strings of any length. In fact, sendmail allows any characters (including NULL) to be in message body. "badmess" was tested with sendmail 8.9.3 + mail.local + UW-pop3d 7.59.

Impact:   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.
Solution:   No solution was available at the time of this entry.
Vendor URL:  www.ritlabs.com/ (Links to External Site)
Cause:   Exception handling error
Underlying OS:  Windows (Me), Windows (NT), Windows (95), Windows (98), Windows (2000)

Message History:   This archive entry is a follow-up to the message listed below.
Apr 20 2001 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



 Source Message Contents

Subject:  Re: SECURITY.NNOV: The Bat! <cr> bug


Hello -mat-,

Saturday, April 21, 2001, 10:19:00 PM, 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 max@ritlabs.com

You're  wrong.  This  message  _is_ RFC 822 and RFC 1251 compliant. In
fact,  RFC  822  absolutely  clear  allows  <CR> and <LF> even in some
message headers:

 text        =  <any CHAR, including bare    ; => atoms, specials,
                     CR & bare LF, but NOT       ;  comments and
                     including CRLF>             ;  quoted-strings are
                                                 ;  NOT recognized.


_any_  pop3  server  shouldn't  change  this message, because RFC 1939
follows RFC 822 for message standard.


RFC  821  (SMTP) simply says "The mail data may contain any of the 128
ASCII character codes".


RFC  1251 allow message to contains any binary data and strings of any
length. In fact, sendmail allows any characters (including NULL) to be
in message body. "badmess" was tested with sendmail 8.9.3 + mail.local
+ UW-pop3d 7.59.

P.S.  I didn't tested The Bat! with NULL characters in message body...
If something like

<CR><LF>NULL.<CR><LF>-ERR

in message body hurts The Bat! badly RitLabs better patch it right now
:)



--
~/3APA3A

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, SecurityGlobal.net LLC