Message-ID: <1279129004.2364.77.camel@vgn-tz31xn>
Date: Wed, 14 Jul 2010 19:36:44 +0200
From: Akita Software Security <lists@...tasecurity.nl>
To: bugtraq@...urityfocus.com
Subject: Outlook PR_ATTACH_METHOD file execution vulnerability

------------------------------------------------------------------------
Outlook PR_ATTACH_METHOD file execution vulnerability
------------------------------------------------------------------------
Yorick Koster, October 2009

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------

It has been discovered that certain e-mail message cause Outlook to
create Windows shortcut-like attachments or messages within Outlook.
Through specially crafted TNEF streams with certain MAPI attachment
properties, it is possible to set a path name to files to be executed.
When a user double clicks on such an attachment or message, Outlook will
proceed to execute the file that is set by the path name value. These
files can be local files, but also file stored remotely for example on a
file share. Exploitation is limited by the fact that its is not 
possible for attackers to supply command line options.

------------------------------------------------------------------------
See also
------------------------------------------------------------------------
- CVE-2010-0266 [2]
- MS10-045 [3] Vulnerability in Microsoft Office Outlook Could Allow
Remote Code Execution (978212)
- Security Research & Defense blog: [4] MS10-045: Microsoft Office
Outlook Remote Code Execution vulnerability
- KB978212 [5] MS10-045: Vulnerability in Microsoft Office Outlook could
allow remote code execution
- KB2271150 [6] You cannot open linked file attachments in Outlook:
"Outlook blocked access to the following potentially unsafe
attachments"
- SSD: [7] SecuriTeam Secure Disclosure program

------------------------------------------------------------------------
Tested version
------------------------------------------------------------------------

This issue was tested on the latest versions of Outlook 2003 SP3 and
Outlook 2007 SP2.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------

Microsoft released MS10-045 [8] that blocks unsafe use of the
PR_ATTACH_METHOD property in e-mail messages.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------

Microsoft Office Outlook is a personal information manager. It is often
mainly used as an e-mail application, but it also includes a calendar,
task manager, contact manager, note taking, a journal and web browsing.

Outlook supports various e-mail formats, including plain text, HTML and
TNEF. TNEF is a proprietary format used by Microsoft Outlook and
Microsoft Exchange Server. TNEF messages or TNEF streams exist of
message and/or attachment attributes. These attributes contain basic
properties, such as message subject, date sent and attachment title
(file name). Additional attributes can be set using MAPI properties,
which are stored in attMAPIProps or attAttachment TNEF structures.

------------------------------------------------------------------------
MAPI attachment properties
------------------------------------------------------------------------

In MAPI, there are a couple of properties available that are specific
for handling e-mail attachments. One of these properties is the
PR_ATTACH_METHOD property. This property can be set to a MAPI-defined
constant and represents the way the contents of an attachment can be
accessed. For most attachments, this property will be set to
ATTACH_BY_VALUE. When set to this value, the attachment data is either
stored in the PR_ATTACH_DATA_BIN MAPI property or it is stored in a
attAttachData TNEF structure.

If the PR_ATTACH_METHOD property is set to ATTACH_BY_REFERENCE,
ATTACH_BY_REF_ONLY or ATTACH_BY_REF_RESOLVE, Outlook expects a
fully-qualified path name instead of an embedded attachment. This path
name is set using either the PR_ATTACH_PATHNAME or
PR_ATTACH_LONG_PATHNAME MAPI property. The path name can be set to a
Universal naming convention (UNC) name.

------------------------------------------------------------------------
ATTACH_BY_REF_RESOLVE
------------------------------------------------------------------------

A message or attachment can have a Message Class property that loosely
defines the type of a message, contact or other personal information
manager objects. For normal e-mail messages, the message class is set to
IPM.Note. The Message Class is set by the TNEF attMessageClass
structure or by the PR_MESSAGE_CLASS MAPI property.

If the Message Class is set to IPM.Document Outlook will process this
message as an e-mail message consisting of a single attachment. By
appending a subclass to IPM.Document it is possible to more specifically
state what type of document the attachment is. For example, a Message
Class of IPM.Document.txtfile indicates that the attachment is a plain
text file, while IPM.Document.Excel.Sheet.12 indicates a Microsoft Excel
document created with Excel 2007.

If Outlook receives a message with its Message Class set to
IPM.Document.<type>, Outlook will search the Windows Registry
using the last part (<type>) of the Message Class to see if such a
file type is registered in Windows. If so, it will look in the Registry
to see if this file type has an icon associated (i.e.
HKEY_CLASSES_ROOT\txtfile\DefaultIcon). If so Outlook uses this icon as
the icon for the e-mail message.

It appears that if Outlook receives a message with a Message Class set
to one of IPM.Document values and it contains a PR_ATTACH_METHOD MAPI
property set to ATTACH_BY_REF_RESOLVE, the message behaves like a
(simple) Windows shortcut. If a user double clicks such a message,
Outlook will open the link provided by the PR_ATTACH_PATHNAME or
PR_ATTACH_LONG_PATHNAME MAPI property.

Setting PR_ATTACH_PATHNAME to cmd.exe causes Outlook to search the PATH
environment variable for an executable named cmd.exe. If such a file is
found, this file will be executed. Normally this will result in a
command shell. The path name can be set to anything that is supported by
Windows, including UNC names (i.e.
\\servername\sharename\executable.exe) but also URLs (i.e.
http://www.akitasecurity.nl/advisory/RunCalc.exe). For URLs, Outlook
will open the default web browser. For other types of URIs, the
registered protocol handler determines how the supplied URI is opened
and by which application.

------------------------------------------------------------------------
Attachment file names
------------------------------------------------------------------------

Even though the attachment can be loaded from a location other than the
message itself, Outlook still processes the file name of attachments. If
none is set and a user double clicks the specially crafted message,
Outlook will show a "Opening File" dialog, warning the user
only to open files from trustworthy sources.

It appears that Outlook uses the file name property to determine if and
if so which dialog must be shown. For example, by setting a fake name
with a .exe extension causes Outlook to show a "File Security
Warning" dialog. In this case users only have the option to save
the file to disk or cancel. The fake name is not checked against the
actual file name provided by the PR_ATTACH_PATHNAME or
PR_ATTACH_LONG_PATHNAME MAPI property. Some extensions do not trigger a
dialog, for example Office files and image files. Consequently, this can
be used to prevent any dialog from being shown even though the actual
file is an executable. File names can be set through the
PR_ATTACH_FILENAME and PR_ATTACH_FILENAME MAPI properties.

------------------------------------------------------------------------
ATTACH_BY_REF_ONLY
------------------------------------------------------------------------

Outlook will not be able to load messages in the preview pane for
messages with the MAPI property PR_ATTACH_METHOD set to
ATTACH_BY_REF_RESOLVE and a Message Class set to one of the IPM.Document
values. Instead it will issue the following notice:

This file cannot be previewed. Try opening the file in the program in
which it was created.

Choosing a different Message Class (i.e. IPM.Note) will allow Outlook to
load the message and the specially crafted attachment will be shown as
a normal attachment. However, if a user tries to open this attachment,
Outlook will issue the following warning dialog:

The program used to create this object is Outlook. That program is not
installed on your computer. To edit this object, you must install a
program that can open the object.

In order to create an attachment containing a link (shortcut), the
PR_ATTACH_METHOD property has to be set to ATTACH_BY_REF_ONLY instead of
ATTACH_BY_REF_RESOLVE. In this case Outlook will look at the extension
of the filename (PR_ATTACH_FILENAME or PR_ATTACH_LONG_FILENAME), but
also at the extension of the path name (PR_ATTACH_PATHNAME or
PR_ATTACH_LONG_PATHNAME). If the path name contains an extension such as
.exe, Outlook will block the attachment. This check can easily be
circumvented using URIs containing query string values ending on a
extension Outlook does not block. For example, the file URI
file:///c:/windows/system32/calc.exe?.txt will cause Outlook to not
block the attachment and still open Calculator.

------------------------------------------------------------------------
Limitations
------------------------------------------------------------------------

This issue does not allow attackers to supply command line options,
limiting the possibilities for attackers when executing local files. It
is possible to place a malicious executable on a file share. In order
for this attack to succeed, the attacker has to be on the same intranet
as the target user or the target user's system has to be allowed to
make outbound connections to the attacker's share (over the
Internet). Note that it is possible to access file shares through WebDAV
(see also Security Research & Defense blog [4]). 

Executables can be delivered of the web (HTTP), but in this case the
file is loaded through the default web browser that will normally issue
a warning when it is about to run an executable.

------------------------------------------------------------------------
References
------------------------------------------------------------------------

[1] http://www.akitasecurity.nl/advisory.php?id=AK20091001
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0266
[3] http://www.microsoft.com/technet/security/bulletin/ms10-045.mspx
[4] 
http://blogs.technet.com/b/srd/archive/2010/07/13/ms10-045-microsoft-office-outlook-remote-code-execution-vulnerability.aspx
[5] http://support.microsoft.com/kb/978212
[6] http://support.microsoft.com/kb/2271150
[7] http://www.beyondsecurity.com/ssd.html
[8] http://www.microsoft.com/technet/security/bulletin/ms10-045.mspx

------------------------------------------------------------------------
-- 
------------------------------------------------------------------------
Akita Software Security (Kvk 37144957)
http://www.akitasecurity.nl/
------------------------------------------------------------------------
Key fingerprint = 5FC0 F50C 8B3A 4A61 7A1F  2BFF 5482 D26E D890 5A65
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5482D26ED8905A65

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists