[20388] in bugtraq
Re: SECURITY.NNOV: The Bat! bug
daemon@ATHENA.MIT.EDU (Nick FitzGerald)
Mon Apr 23 16:28:02 2001
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Message-ID: <200104230008.MAA02452@fep3-orange.clear.net.nz>
Date: Mon, 23 Apr 2001 12:06:21 +1300
Reply-To: nick@virus-l.demon.co.uk
From: Nick FitzGerald <nick@virus-l.demon.co.uk>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <01042120190001.05610@elektrobarde>
> This is not a bug of The Bat! but a bug of MTA (POP3/SMTP servers)
> that allow such odd messages. The proposed "bad-message"
> (http://www.security.nnov.ru/files/badmess.zip) is not
> RFC-compliant. Any RFC-compliant POP3/SMTP server must either
> bounce or cure it. I've used a proposed example to send the
> message to myself, on a FreeBSD server with Sendmail 8.11.1 I've
> typed cat badmess | sendmail -U max@ritlabs.com
>
> This message has been received by a KSI-Linux server with sendmail
> 8.8.8 and the POP3 to retrieve was Marc Crispin's daemon v2000.69.
>
> The message has been received with orphaned LF's replaced to CR-LF
> pairs. Some MTA software in transit has cured the message.
>
> The Bat! could bounce such odd messages but it doesn't do it
> intentionally because there are some odd mailserver that use
> single LF as a line endings. These servers, however, will quote
> the dot in the end of line and the proposed "bad-message" won't
> work with them either.
This raises a question I considered asking when everyone was hopping
up and down about how crappy it was of MS to have an exploitable
buffer overflow in the date-handling code of Outlook and Outlook
Express...
The authors of TheBat! suggest above that this problem should not be
their concern because the message should never arrive in such a state
as it is clearly not standards-compliant. The same could be said of
the Outlook/OE date header problem which, IIRC, required an
unfeasibly long timezone value. "Unfeasible" how? Unfeasible
according to the SMTP STD which effectively defined a maximum length
for the Date: header's value of 30-something characters (I don't have
the notes I made at the time and can't be bothered checking but it
was well short of the length needed in just in the TZ part of the
header to trigger the overflow).
Sure overflows are bad and undesirable (they reflect something about
the general levl of quality and security consciousness of the
programmers if nothing else), but is not the real problem here that
SMTP servers accept non-compliant messages in the first place **and
pass them on thus**?
Rather than pouring scorn on MS for the crappiness of the Outlook/OE
date-parsing code as if they were the "real villians" in that case,
shouldn't we have been pouring the scorn on the authors of the
non-standards compliant servers that pass these messages?
(Of course, in the Outlook/OE case, that would have included the MS
programers who wrote Exchange...)
I was reminded of this again recently because a Notes user on another
list complained that a list "control" message they sent was bounced.
That list processer reads its commands from the Subject: line and
it turned out that the combination of Notes client and Notes SMTP
gateway happily sent a non-standards compliant message, failing to
put the required blank line at the end of the message header block.
It was the SMTP server on the list processer machine, not the list
processor, that rejected the message, and it did so because it was
not a valid message according to the standards (a message can have a
null body but the header block ends with the first blank line).
The scant regard with which such standards are treated by so many
large developers leads to all manner of ugliness, not least of which
have security implications. Another example is the way MS web
browsers treat ("ignore") content-type information from the server --
who would expect a GIF file to be scanned for <HTML> (or similar)
tags and parsed as HTML, rather than displayed as a GIF, if such were
found in the comment field? Given that happens, what other files
commonly handled by your browser can have HTML-bombs embedded in
them? Similarly, should a browser skip over kilobytes of binary junk
at the head of a file and interpret HTML just because it eventually
found an <HTML> tag buried in the file? If MS did not write IE to
do this the fact that MS' Scriptlet.TypeLib ActiveX control was
incorrectly shipped as "safe for scripting" might scarcely have
mattered because a modest amount of such binary junk is unavoidable
in writing a TyepLibrary using the Scriptlet.TypeLib control. If IE
was not so keen to find HTML, it would never have been able to find
(and thus never run) the JS and VBS scripts that are now commonly
dropped into HTA (HTML Application) files via the Scriptlet.TypeLib
hole, thus that hole could not have been so readily used (and
probably could not have been used for useful exploits at all --
perhaps for some annoying local DoS and Trojan effects though). (For
those who don't know -- some spammers have been using this hole to
add "Favorites" to IE and even change its start page to point to
their sites, and of course it has been extensively used by several
viruses...)
Regards,
Nick FitzGerald
