PSE-L(_at_)mail(_dot_)professional(_dot_)org (Professional Software
Engineering) writes:
At 22:31 2001-11-30 +0000, John Conover wrote:
Unfortunately, there is a problem with the way Microsoft Outlook
parses e-mail headers. For example, in BadTrans.B:
Correction: don't you mean, "unfortunatley, there's a problem with how MS
OutBreak (or at least the virus) _sends_ messages? Being more lenient with
interpreting something isn't inherently a problem -- failing to adhere to
the spec when writing it is quite another (and is something microsoft will
always be guilty of).
Being more lenient when interpreting, when it goes outside the bounds
of a specification, very often _is_ a security problem, as demonstrated
by this very case. This has been discovered repeatedly in the past by
various groups including DNS developers*, Intrusion Detection System
researchers**, and users of various programs that ignore how data is
tagged (plain-text vs HTML vs GIF, etc) and opportunisticly interpret
it as some 'richer' format (like HTML or Word)***.
According to the standards governing email messages, the message did
*not* contain an attachment. It thereby evaded two mail filters, one in
procmail and one in NAI's WebShield product. That Outlook interpreted
it as an attachment is a security hole in Outlook and someone should
a) confirm it by testing on the specified version of Outlook (or Outlook
Express?), as well as the current (patched) version
b) if it still exists, inform security(_at_)microsoft(_dot_)com
c) request details of under what circumstances the buggy program will
misinterpret messages in this way (this is required so that people
writing filters can extend their protection to unpatched versions
of Outlook)
d) post to bugtraq (possibly after waiting for Microsoft to patch Outlook)
What's particularly problematical with this case is that a message may
be syntactically correct as is! For example, the following two lines,
while semantically incorrect (the boundary parameter is required with
multipart content-types) are both syntactically correct header fields!
Content-Type: multipart/related
;boundary="====_AB:C1234567890DEF_===="
Are *you* sure how Outlook will interpret that? I'm not.
If you're willing assume that Outlook will only misinterpret messages
where the last token in the Content-Type: field's value is a semicolon,
then you could use the following recipe to munge headers:
sub = 's/^\([^ :][^:]*\)$/ \1/'
:0 fhw
* ^content-type[ ]*:.*;[ ]*$[^ ][^:]*=
|sed "$sub"
(By putting the sed expression into a variable we avoid a shell)
That would of course go above your other filtering recipes.
Philip Guenther
*
http://www.usenix.org/publications/library/proceedings/security95/full_papers/vixie.txt
** How a series of TCP/IP packets will be interpreted by a system is
heavily dependent on the Operating System and its version. An IDS
therefore cannot, in general, determine how an end machine will react.
Such packet streams can occur accidentally or by error and are not always
the result malicious acts...
*** If my memory serves, this behavior in IE has been discussed on
bugtraq sometime in the last year or so.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail