Message-ID: <004901c42a05$43f131e0$c864a8c0@win98>
From: orchestra at ttnet.net.tr (Orchestra)
Subject: Que es mas macho, SCRIPTES o TABLESPOON?

This post is a bit humorous due to the funny things happening when Outlook
Express renders plain text messages.

Security problem here is ability of Outlook Express to interpret a plain text as
HTML, thus allowing tags and scripts. This is possible because, OE have no
separate plain text renderer, but use its HTML renderer instead, by converting
plain text to HTML, and giving plain text appearance. Obviously not a good
choice for security. In order to achieve this, OE first apply HTML encoding to
the message, i.e converting "<" to "&lt;"  in order the content of the message
does interfere with HTML . Then it  insert BR tag to end of each  line and may
other tags like HR required to format the message. But as it was discovered by
http-equiv@...ite.com in BugTraq posting "Subject: FREAK SHOW: Outlook
Express 6.00", dated September 12, 2001, it is possible to bypass this filter.
The exact requirement on this discovery is the whole message should be less
than 64 bytes and should include some specific HTML (elements) tags. I was
aware of this strange behaviour of Outlook Express in various of versions
before, but did not thought it could pose a security issue.

This behaviour can be extended by below methods:

1) It is possible display more than one part of "multiple part" message in the
same page. The trick is the first part  satisfy the http-equiv exploit, thus
disabling the HTML encode filtering. interestingly, filter does not reactivated
when the second part of the message is rendered. There is no size limit on this
part, therefore anything be written in HTML format is rendered as HTML despite
the mime type is specified as "text/plain".

2) It is possible to remove the 64 bytes limit of the bug by putting a binary
zero within this 64 bytes area using various mime encoding schemes
(i.e. "=00" in quoted-printable). But recall that the filtering is disabled if
only suitable HTML tags is present in this section. These are PRE, SCRIPT,
BODY, IMG, TITLE, HEAD, PRE, TABLE, HTML, I found so far. Which make
it so funny is HTML parser does not test these tags as a complete words,
therefore one can add additional characters to obtain derivative tags. Few of
them are PRESTO, SCRIPTES,TITLESS, BODYMASSAGE, IMGAYAMA,
HEADINGO, PREGNANT and TABLESPOON. Note that these extended tags
appears not functional in HTML, except the satisfying the filtering disabling
condition. (It is even not required to close the tag. One can see how sloppy
M$ programs are.)

3) There is another bug in rendering sequence where the HTML filtering is done
before character set decoding is made. This condition arise when "charset" type
is not specified in the mime header but by the signature placed to the beginning
of the message. UTF-7 and UTF-8 signatures, signal to renderer decode the
message according these encoding methods. The bug is this decoding take
place after the HTML filtering, therefore characters like angle brackets are not
filtered if  they are encoded. So HTML tags written inside UTF-7 encoded angle
brackets are not appears as text on screen but processed instead. UTF-8 scheme
appears no longer work in OE 6.0 on my machine, but UTF-7 is always working
for many years.  Combined the cross-mime parts feature of Outlook Express,
it is possible to create messages difficult to analysis.

Now, how these plain text message may pose a security issue?

First, email filters can be bypassed, if they sensitive to mime types. One can
think an email filter should not filter messages whey found some script
sequences in plain text messages, but they should do.

Next, it is possible to embed script codes or images using news sites "Send
to a friend" feature. UTF-7 both allow to bypass filters of these services, and
even they allow plain text messages they can be used for malicious purposes.
using this scheme it is possible to build a web based worms which not requiring
ActiveX controls, but simply using the above news services to spread themselves.
Email address not needed be fetched from local machine, but from the Internet
by using search engines or by other methods.

Finally, it exist a DoS condition in OE 6.0 by simply writing "Ky92OS0g" in
message body with mime Content-Transfer-Encoding: base64.

Hamdi Ucar
Orchestra Communication Systems

Powered by blists - more mailing lists