full-disclosure - Outlook Express Attachment Property Spoofing Vulnerabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <00b601c22fa8$a086df80$e62d1c41@kc.rr.com>
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Outlook Express Attachment Property Spoofing Vulnerabilities

[ Outlook *may* be vulnerable; I do not have a supported
version to test for these flaws ]

There are several vulnerabilities in Outlook Express 6.0 (and
some may apply to OE 5.01/5.5, as well) that affect how the
MUA represents attachments.  These vulnerabilities allow a
malicious e-mail to:

1) Spoof the size of an attachment.
2) Misrepresent the extension of an attachment in the "Open
    Attachment Warning" dialog.
3) Set an attachment's icon to the default
4) Bypass the malicious file type filter
5) Also, misrepresent the name of the attachment in the
    "Attachments" listbox.

Filter Bypass (Content-Disposition/Type headers)
--------------------------------------------------

This vulnerability occurs when an e-mail does something similar to
the following in an attachment boundary:

Content-Type: application/asx
Content-Disposition: inline; filename="newtitle.chm"

This simple exploit of these vulnerabilities only allows a malicious
file to slip through the filter -- although more advanced ones will
do more fun things. :-XD

Listbox Name/Size Spoofing (Item truncation)
----------------------------------------------

A default Windows behavior turned into a security vulnerability. :-)
If we give Outlook Express a long name of an attachment, something
like "newtitle.chm (45.6 KB)           [...]", we can cause the size not
to appear in the OE attachments list correctly, and instead force it
to display our incorrect size.

A more advanced exploit of this is "newtitle.asx (45.6 KB)   [...].chm"
This way, the user doesn't see the true extension of the file.  At least,
until the attachment warning.  This can be bypassed, as well, however...

Open Attachment Warning (Messy space handling)
---------------------------------------------------

In the OE "Open Attachment Warning" prompt, strange behavior occurs
when file names contain spaces, such as "newtitle.asx .chm".  Everything
after the space is clipped, as well as the space itself.  This can result in
the above attack being masked to the user in the area that is normally
thought of as the last line of defense -- the attachment warning.

[NOTE: In some cases, the MUA will clip the entire attachment name,
especially if it is rather long.  This will cause the target of the open
action
to appear as the cache folder.  I have not isolated the cause of this.]

Default Icon Spoofing (Dot bugs, again)
----------------------------------------

We have the name of the attachment perfectly spoofed, and that's great,
but that CHM icon is still there!  Rest assured, there is also a way around
this. :-)

By appending 2 or more 0x2E characters (".") to the end of a filename,
Outlook Express will fail to identify an icon for the file, making the user
believe it is not any registered file type.

Exploit: http://www.murphy.101main.net/Oe6_issues.eml

Vendor:

Microsoft was notified June 28, and assigned case # MSRC-1201 to the
issue.  Aside from asking for examples, they have not given any further
indication of progress.  I have not heard from MS since July 8, despite
repeated requests that I be informed of progress (therefore, I must assume
none has been made).

"The reason the mainstream is thought
of as a stream is because it is
so shallow."
                     - Author Unknown