A subject line buffer overflow in Outlook Express (was Re: EML Content Spoofing and Informed Consent)

----- Original Message -----
From: "Dan Kaminsky" <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 04, 2001 5:52 PM
Subject: EML Content Spoofing and Informed Consent (was: Re: MS patch
Q292108 opens a vulnerability)

[snip]
>
> [The short version of this: If I try to open a MP3 file remotely, and I
> actually execute a Word Macro Document or even a full fledged install of
> BackOrifice, I'm the victim of a security hole: My ruleset for choosing
> what to download was tricked; the trust I applied to one format(MP3) was
> used upon another(EXE, DOC). The rest of this is essentially a quick
> refresher in security theory for whoever at MS argued that "querying the
> user, even with a spoofed query, means no security hole.", along with a
> surprising connection to bioethics.]
>
> Good example of why full disclosure is useful–I went ahead and checked
out
> the demo myself, and immediately found that Microsoft's argument holds
> little water. Essentially, there's a simple rule of browser security that
> states that explicitly asking the user to authorize a transaction with an
> informed set of validated security parameters is more secure than simply
> having a default list of parameters that must be satisfied and
automatically
> accepting if that list is accepted.

In the interest of full disclosure, and because Microsoft has given us the
exact same answer to this, a buffer overflow exists in the subject line
buffer of Outlook Express, versions 5.0.x.x and 5.50.x.x. This overflow is
exploitable (in the latter version) with the same EML content spoofing being
discussed in the previous thread.

One of my techs, Su Wadlow, did some testing after we had problems with
Outlook Express clients crashing when trying to read a certain VP's email.
(He likes to send email with excessively long subject lines, such as the
entire first paragraph of his email message.)

If a subject line with more than 256 characters is constructed, OE will
overflow and crash (ver 5.0.x.x) or construct an attachment out of the
message body (OE 5.50.x.x). (Su read a post in vuln-dev discussing a buffer
overflow in the news reader of OE, and putting two and two together decided
that must be what was happening in OE's subject line. I asked her to do
some testing, and she found that the buffer could be overflowed
inconsistently with as few as 161 characters [no determination as to cause
other than length] and consistently with 256 characters.)

This bug was identified and posted on malware.com's site in January of this
year. I don't know of any earlier discussions of it. Malware.com claims
this bug exists in Outlook as well, but we have been unable to reproduce
that.

If you visit the malware.com site (http://www.malware.com/dropper.html&#41;, you
will find some proof of concept exploits that demonstrate how this bug can
be exploited to run any application you want on the victim's machine by
"fooling" them with a fake icon. (This would only work in the later
versions. Ver. 5.0.x.x will crash. We didn't test any older versions such
as 4.x)

We corresponded with MS Security about this issue, but they will not do
anything unless we provide them with a proof of concept exploit. Since we
aren't in the exploit business (and have many other things to do), I sent a
copy of all this to Georg Guniski and asked him if he could craft an exploit
that would convince MS that this is a very real problem, but I haven't heard
back from him. I don't know if he is working on it or not. I don't know if
the BO in the earlier versions could be exploited, but since one of my many
responsibilities is anti-virus protection for our campus, the behavior of
the later versions (5.50.x.x) bothers me a great deal, and I'm very
disappointed that MS passes it off as a "user education" issue. Since this
bug creates an "attachment" that isn't identified by the headers, I wonder
if virus scanners would even catch anything crafted in this fashion.

I suspect the crashed version could be exploited by someone who understand
registers and assembly well enough. A convenient copy of the Dr. Watson log
will show you exactly where in the stack the overflow occurs.

<rant>When are CS departments going to start teaching proper bounds
checking??? And when are programmers going to start using it???</rant>

Paul Schmehl [email protected]
Supervisor, Support Services
University of Texas at Dallas
AVIEN Founding Member