------------------------------------------------------------------------
Office arbitrary ClickOnce application execution vulnerability
------------------------------------------------------------------------
Yorick Koster, June 2010
------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A logic flaw has been found in the way .NET grants permissions to
ClickOnce applications. Combined with relaxed security warnings when
handling OLE Packages in Office 2007 allows for attackers to run
arbitrary .NET assemblies with Full Trust permissions.
------------------------------------------------------------------------
See also
------------------------------------------------------------------------
- CVE-2012-0013 [2]
- MS12-005 [3] Vulnerability in Microsoft Windows Could Allow Remote
Code Execution (2584146)
- KB2584146 [4] MS12-005: Vulnerability in Microsoft Windows could allow
remote code execution: January 10, 2012
- SSD: [5] SecuriTeam Secure Disclosure program
------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on Office 2007 SP2 running on both
Windows Vista SP2 and Windows 7.
------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
Microsoft released MS12-005 [3] that changes the way that Windows
Packager identifies unsafe files.
------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
ClickOnce is a deployment technology that allows you to create
self-updating Windows-based applications that can be installed and run
with minimal user interaction. A ClickOnce application is any Windows
Forms or Console application published using ClickOnce technology.
Applications can be published from a web page, a file share, or from
media (i.e. CD-ROM). ClickOnce is available in .NET 2.0 and later.
An application that is deployed through ClickOnce consists of at least
three files; a deployment manifest (.application), an application
manifest (.exe.manifest) and the application. The application is usually
renamed to a .deploy file in order to ease deployment of the
application over the web.
Runtime protection is provided through the .NET Code Access Security
(CAS) infrastructure. Security is applied at the application level,
instead of the individual assembly level as it is in a normal .NET
application. The entire ClickOnce application is treated as as single
unit. The application manifest specifies what security permissions the
application needs to run.
At launch, the URL or UNC path from which the application is deployed is
evaluated by the runtime. Using the deployment path, the application is
associated with one of the following security zones; Local Machine,
Intranet, Internet, Trusted Sites or Restricted Sites. Based on this
zone, the runtime grants the application a default set of permissions.
Through the application manifest, the application can request its own
permissions. If these permissions are equal or less than the granted
permissions (based on security zone), then the application is allowed to
run. If elevation of permissions is required, a security warning dialog
will be presented to the user in which the user can choose to Run (or
sometimes Install) or Don't Run the application.
http://www.akitasecurity.nl/advisory/AK20100601/001-clickonce_application_run_security_warning.png
Figure 1: Application run security dialog.
Applications deployed through ClickOnce can run as Partial Trust, but it
is also possible to request Full Trust permissions. The runtime can
grant these permissions either through the user (using a security
warning) or if the application is deployed from the Local Machine
security zone. A Full Trust application is the equivalent of a native
application. It runs with the privileges of the user running this
application.
------------------------------------------------------------------------
ClickOnce attachments
------------------------------------------------------------------------
All versions of Outlook since Outlook 2000 Service Release 1 (SR1)
include a security feature that blocks attachments that might put
computers at risk for viruses or other threats. Amongst these
attachments are executables (.exe, .com, .cmd & .scr), scripts
(.hta, .js, .vbs & .wsf) and other types of potentially dangerous
files (.cer, .hlp, .inf & .reg). This helps protect unsuspecting
users from running malicious code.
Normally, when a user tries to open an e-mail attachment, the user is
presented an Opening Mail Attachment dialog. If the user chooses to open
the file, the file is saved locally and handed off to Windows. Windows
will try to find a program associated to this specific type of file
(through its extension). If such a program is found, Windows will launch
the file according to its Shell Open Command in the Windows Registry.
http://www.akitasecurity.nl/advisory/AK20100601/002-outlook_open_mail_attachment.png
Figure 2: Opening Mail Attachment dialog.
For certain files, Outlook does not show the open dialog, but instead
proceeds with opening the attachment. Amongst these files are Microsoft
Office files (except for .mdb files, which are blocked), PDF documents
and image files. In addition, this is also true for files with the
extension .xaml, .xbap or .application. These extensions are normally
used by the .NET technologies XAML Browser Application (.xaml &
.xbap) and ClickOnce (.application). If the correct version of the .NET
Framework is installed, opening these type of attachments will start the
associated .NET application(s).
As noted above, Outlook does not block ClickOnce deployment manifest
files (.application). If an deployment manifest is sent as attachment
and a user opens this attachment, it will be opened immediately. The
application and application manifest can be hosted on a web site or file
share. In this case, needed files will be downloaded and the
application can be launched with the permissions associated with either
the Internet or Intranet security zone (depending on the download
location and as requested in the application manifest).
If no elevated permissions are requested, the application is launched
without any warning dialog. Instead the .NET Framework presents a
warning message in which users are warned not to enter personal
information or passwords in the displayed window unless they trust its
source (see figure below).
http://www.akitasecurity.nl/advisory/AK20100601/003-clickonce_internet_zone_warning.png
Figure 3: Security warning for applications running in the Internet
zone.
ClickOnce applications may request more permission than granted by its
security zone. If the application requests more permissions, the
Run/Don't Run dialog is shown (see figure 1).
ClickOnce deployment manifests are not blocked by Outlook, consequently
this provides attackers a way of distributing malware through e-mail
messages. Since e-mail messages are easily spoofed, users may be
convinced in running these malicious applications as they believe the
attachment was send by a trusted person. For Full Trust applications
(most malware will need Full Trust permissions) it is still required
that users click Run in the security warning dialog.
------------------------------------------------------------------------
ClickOnce security zones versus Internet Explorer security zones
------------------------------------------------------------------------
Security zones in ClickOnce applications are similar to those in
Internet Explorer. There are some differences in how both technologies
handle security zones. Most important differences are:
- Evaluation of security zones.
- Permissions in the Local Machine security zone.
Evaluation of security zones
When a ClickOnce application is launched, the launcher checks the
deployment manifest to determine which permissions are requested. In
addition, the location of the deployment manifest, the application
manifest and the application are checked. The minimal set of permissions
is applied to the ClickOnce application, elevation of these privileges
is only possible through the user. For example, the deployment
application is launched locally, but the the application manifest and
the application are obtained from a website, than the application will
run in the Internet security zone (or possible the Trusted Sites or
Restricted Sites security zones). The permissions are granted based on
the fact that the the application manifest and the application are
obtained from a website.
In Internet Explorer, the security zone is first of all determined using
the location from which a particular web page (or file) is loaded. In
addition it is possible to load a file in a less privileged security
zone through one of the following mechanisms:
- Mark of the Web (MOTW).
- Zone.Identifier Alternate Data Stream.
- Page is loaded from a special folder, such as the Temporary Internet
Files folder.
Elevation to a higher privileged security zone is not possible through
the listed mechanisms. ClickOnce does not support these mechanisms when
evaluating the security zone of a ClickOnce application. Thus if an
ClickOnce application is started from the Temporary Internet Files
folder and the application manifest and the application are also on the
local computer (and referenced in the application manifest), the
application is started with Full Trust permissions.
Testing shows that to some degree, ClickOnce does check whether it is
loaded from the Temporary Internet Files folder. In such a situation,
ClickOnce will show a warning dialog similar to the dialog shown in
figure 1. This specifically happens when the ClickOnce application files
are saved in the Temporary Internet Files folder using Internet
Explorer; for example using object tags with the type attribute set to
text/plain. If the deployment manifest is opened (i.e. using Windows
Explorer), the warning is shown.
Permissions in the Local Machine security zone
Prior to Windows XP Service Pack 2 if a web page was loaded in the Local
Machine security zone, it was granted full privileges. For example, it
could read local files or worse invoke an unsafe ActiveX control and
gain full control of the target machine. In Service Pack 2, Microsoft
introduced the Local Machine Zone Lockdown that greatly reduced the
privileges of web pages running in the Local Machine zone. With
ClickOnce, applications running in the Local Machine security zone are
granted Full Trust permissions.
These differences in handling security zones provided attackers a window
of opportunity to trick target users in running (malicious) ClickOnce
applications with Full Trust permissions. The following paragraphs
provide a couple of examples (attack vectors) that show how Office can
be abused to run ClickOnce applications with Full Trust permissions.
Each example requires some user interaction, the amount of required user
interaction depends on the chosen attack vector.
------------------------------------------------------------------------
OLE Packages
------------------------------------------------------------------------
Object Linking and Embedding (OLE) allows embedding and linking to
documents and other objects. Embedding of arbitrary files is possible
through OLE Packages. Embedding a document as OLE Package can be as easy
as dragging and dropping the document in the target document, such as a
Microsoft Word document. The embedded document can be opened by double
clicking its icon. Most applications allow reformatting of OLE Packages,
i.e. changing the Package's icon and label.
http://www.akitasecurity.nl/advisory/AK20100601/004-ole_packages.png
Figure 4: OLE Package examples.
OLE Packages can also be created using Windows Object Packager
(packager.exe). Note that this application is no longer available in
Windows Vista and later.
If an OLE Package is opened, it is first extracted to a temporary folder
from which the file is opened. Consequently, using an OLE Package it is
possible to run a ClickOnce deployment manifest from the local machine
by tricking the target user into double clicking the OLE Package. If the
attacker also manages to store the application manifest and application
locally, it is possible to run the application with Full Trust
permissions. Storing these files locally may also be achieved through
OLE Packages. This requires a significant amount of user interaction.
Depending on the target application, the user may also be presented with
additional (warning) dialogs. For example, if any OLE Package is opened
in an Office 2003 application, the user is presented with a waring
dialog. In Office 2007 a dialog is only shown for specific file types,
no dialog is presented if a user opens an ClickOnce deployment manifest
file.
http://www.akitasecurity.nl/advisory/AK20100601/005-office2003_ole_package_warning.png
Figure 5: Warning dialog in Word 2003 when opening an OLE Package.
------------------------------------------------------------------------
Word 2007
------------------------------------------------------------------------
As stated above, the number of warning dialogs in Office 2007 when
opening OLE Packages, is significantly reduced compared to Office 2003.
Specifically, the files needed to run a ClickOnce application don't
trigger a warning dialog when opened. Consequently, an attacker can
embed an entire ClickOnce application in an Office document. Using
social engineering it is possible to trick users into opening these
Packages. When opened, the embedded files are saved in the same
temporary folder. If the Packages are opened in the correct order, the
ClickOnce application will run with Full Trust permissions. This does
require a significant amount of user interaction making a successful
attack less likely. In addition, when opening the application manifest
(.exe.manifest) and the application (.exe.deploy), by default, Windows
does not know how to handle these type of files (i.e. no program is
registered to handles these file types). Windows will show a dialog
asking the user how the file should be opened (see figure 6).
http://www.akitasecurity.nl/advisory/AK20100601/006-windows_cannot_open_file.png
Figure 6: Windows cannot open this file.
It appears that if an OLE Package is selected in Word (i.e. clicking the
object once), the embedded file is also saved locally. If an attacker
can trick the user into performing the following actions, it is also
possible to execute the ClickOnce application:
- select embedded application manifest;
- select embedded deploy file (the application);
- open embedded deployment manifest.
Just selecting the OLE Package will not result in the dialog as shown in
figure 6. To make a successful attack more likely, an attacker can
format the OLE Package such that it does not look like an embedded file.
A proof of concept was created that utilizes these techniques to create
a very simple game. If the user follows the provided instructions, the
user will launch the ClickOnce application.
http://www.akitasecurity.nl/advisory/AK20100601/007-word_2007_game_poc.png
Figure 7: Screenshot of Word proof of concept.
------------------------------------------------------------------------
PowerPoint 2007
------------------------------------------------------------------------
PowerPoint allows for Custom Animations to be set for OLE Packages.
Besides the regular animations, we have the option to set two OLE
specific animations (named Object Actions); Activate Contents & Edit
Package. Activate Contents performs the same actions as if the user
double clicks the embedded object. Thus using Custom Animations it is
possible to perform a particular sequence of actions, allowing us to
execute an embedded ClickOnce application with Full Trust permissions.
Doing so will trigger a series of dialog windows, such as the one shown
in figure 6. However there is no need for the user to interact with
these dialog windows. Custom Animations are executed when the PowerPoint
is displayed in Slide Show mode (for example by pressing F5 or double
clicking a .pps or .ppsx file). Since Slide Shows are shown full screen
and focus is regained when an Animation action is executed, it is
possible to hide these dialogs. If the ClickOnce application is launched
it will be possible to send a Windows Message to the dialogs so there
are closed automatically.
On Windows Vista and later, the Edit Package Animation will also cause a
copy of the embedded file to be saved locally. This option will show a
window in which the user can change the label of the OLE Package. Using
this option will block the current Custom Animation until the user
closes the window. Closing the window is (amongst other ways) possible
by clicking the OK or Cancel button, pressing <Alt>+<F4> or
clicking the close button in the title bar. No matter what the user
chooses, the temporary file will persist locally until the PowerPoint
presentation is closed. Consequently, user interaction is required,
however the only way to stop the exploit from running is by closing
PowerPoint through Task Manager.
------------------------------------------------------------------------
Macros
------------------------------------------------------------------------
It is also possible to perform the steps used in the PowerPoint examples
using Macros. The following Macro will open all embedded OLE Packages
within an Office document:
Private Sub Document_Open()
Dim i As Integer
For i = 1 To ActiveDocument.InlineShapes.Count
ActiveDocument.InlineShapes(i).OLEFormat.Activate
Next i
End Sub
------------------------------------------------------------------------
Windows XP
------------------------------------------------------------------------
Exploiting this issue on Windows XP using the above described attack
vectors will fail. This is caused by the fact that on Windows XP OLE
Packages are handled by the packager.exe application (Windows Object
Packager) while on Windows Vista and later OLE Packages are handled by
the DLL packager.dll. This is defined in the Registry key
HKEY_CLASSES_ROOT\Package\protocol\StdFileEditing\server. Big difference
between these two is that on Windows XP the temporary file is removed
if packager.exe is closed, while on Windows Vista the file is removed
when the Office document is closed (and the DLL is unloaded). Also the
exe saves its files in the Temporary Internet Files folder while the DLL
uses the user's temporary folder (i.e.
C:\Users\<username>\AppData\Local\Temp).
When an embedded ClickOnce application is launched through its
deployment manifest, the dfsvc.exe service is started. This process is
started detached from packager.exe, which causes packager.exe to think
that the action has finished, causing it to close itself and thus remove
the temporary deployment manifest. This creates a race condition as the
ClickOnce service will try to parse the deployment manifest. As this
file is (in most cases) removed by packager.exe it will fail to do so
and an error message will be displayed.
------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] http://www.akitasecurity.nl/advisory.html?id=AK20100601
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0013
[3] http://technet.microsoft.com/en-us/security/bulletin/ms12-005
[4] http://support.microsoft.com/kb/2584146
[5] http://www.beyondsecurity.com/ssd.html
------------------------------------------------------------------------
--
------------------------------------------------------------------------
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
Attachment:
signature.asc
Description: This is a digitally signed message part