[20394] in bugtraq
Re: SECURITY.NNOV: The Bat! bug
daemon@ATHENA.MIT.EDU (Peter van Dijk)
Mon Apr 23 18:55:11 2001
Mail-Followup-To: BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID: <20010423223546.A17742@dataloss.nl>
Date: Mon, 23 Apr 2001 22:35:46 +0200
Reply-To: Peter van Dijk <peter@DATALOSS.NL>
From: Peter van Dijk <peter@DATALOSS.NL>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200104230008.MAA02452@fep3-orange.clear.net.nz>; from
nick@VIRUS-L.DEMON.CO.UK on Mon, Apr 23, 2001 at 12:06:21PM +1300
On Mon, Apr 23, 2001 at 12:06:21PM +1300, Nick FitzGerald wrote:
> 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
They're wrong.
> 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**?
Not at all. SMTP servers are concerned with RFC821 (SMTP), not RFC822
(message format). The only place where SMTP and RFC822 touch is in the
adding of Received headers. Everything else is purely between the
original sender and the final recipient.
Lots of MTA's, however, try to enforce RFC821 compliance on
SMTP-received and -transferred messages. All of them fail miserably,
mutilating messages in the process and basically harming
interoperability and message integrity.
> 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?
No. Even if we would agree that those people are wrong (which I
disagree to), that still leaves the Outlook/OE hole open to exploit
for a 'malicious' server (either intentional or because it got
hacked). That alone is reason enough to indeed blame M$ for that bug
(and the The Bat! authors for this one, ofcourse).
Greetz, Peter.
