Office arbitrary ClickOnce application execution vulnerability
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.
- MS12-005 Vulnerability in Microsoft Windows Could Allow Remote Code Execution (2584146)
- KB2584146 MS12-005: Vulnerability in Microsoft Windows could allow remote code execution: January 10, 2012
- SSD: SecuriTeam Secure Disclosure program
- Exploit Shop MS12-005 : embedded object package allow arbitrary code execution
This issue was successfully tested on Office 2007 SP2 running on both Windows Vista SP2 and Windows 7.
Microsoft released MS12-005 that changes the way that Windows Packager identifies unsafe files.
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.
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.
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.
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).
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.
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.
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.
Figure 5: Warning dialog in Word 2003 when opening an OLE Package.
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).
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.
Figure 7: Screenshot of Word proof of concept.
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.
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
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.