> 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 maxat_private > > 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
This archive was generated by hypermail 2b30 : Mon Apr 23 2001 - 13:25:48 PDT