While investigating a few of the exploits associated with the recent HackingTeam compromise, I realized an aspect of the Windows User Account Control (UAC) that might not be widely known. Microsoft has published documents that indicate that the UAC is not a security boundary. For these or other reasons, some folks may have disabled the UAC on their Windows systems. I will explain in this blog post why disabling the UAC is a bad idea.

First introduced with Vista, the UAC was annoying to many, which caused some folks to disable it as shown in the screenshot below. The point of the UAC was to steer application developers to accept a world where their users do not have administrative privileges all of the time. This change is a good thing. It's the unexpected consequences of disabling the UAC that can get people in trouble.

Consequence #1: Internet Explorer

Starting with Windows Vista, Internet Explorer Protected Mode was introduced. Protected Mode in Internet Explorer is made possible through the use of Windows integrity levels. A low-integrity process has fewer privileges than a standard user on Windows, and a high-integrity process has administrative privileges. Protected Mode makes it more difficult for attackers to cause harm to a system. The following screenshot is Process Explorer showing Internet Explorer running in Protected Mode:

If UAC is disabled, then IE Protected Mode is also disabled. What this means is if a vulnerability is triggered via Internet Explorer, then the resulting code that executes should have the same privileges as the logged-on user. If you're logged on as an administrator, then the code will execute with a high integrity, and subsequently administrative privileges.

The following screenshot shows Internet Explorer running on a system with UAC disabled, and subsequently IE Protected Mode disabled:

Consequence #2: Microsoft Office

Starting with Office 2010, Microsoft introduced Protected View, which has some similar properties to Internet Explorer's Protected Mode. Protected View may be enabled for a number of reasons, including when the file is downloaded from an internet location. In addition to running with low integrity, Office Protected View also disables plugins such as Adobe Flash. Given the recent vulnerability in Flash, this should help protect users.

Here is a screenshot of the Process Explorer view of Word 2013 when launched from Internet Explorer on a Windows 7 system:

Just like disabling the UAC will disable Protected Mode with Internet Explorer, disabling the UAC will also disable Microsoft Office Protected View when Office is launched from Internet Explorer. What this means is not only will the Office applications lose the benefit of low integrity, they will also run plugins such as Adobe Flash without prompting the user!

Here's a screenshot of Process Explorer on a system with the UAC disabled, after opening a DOCX file that exploits Adobe Flash vulnerability VU#561288:

Not only was the proof-of-concept exploit successful (with no user interaction required beyond opening the DOCX file), but the resulting instance of calc.exe runs with high integrity. Since I was logged on as a user with administrative privileges, the code that executes from the exploit also runs with administrative privileges.

One important aspect of the Protected View situation is that the above symptoms of Protected Mode were demonstrated when Word was launched from the Internet Explorer browser. Why does the browser make a difference? It seems to be related to how Office knows where a file was downloaded: Mark of the Web (MOTW).

MOTW

Modern Windows applications, such as Internet Explorer, Outlook, Firefox, and Chrome, will flag downloaded files with the appropriate MOTW marking. For non-HTML content, the MOTW is implemented as an NTFS Alternate Data Stream (ADS).

When applications such as Microsoft Office open such a file, they can check whether or not the file is trusted. For example, if Microsoft Word opens a DOCX file with a MOTW tag indicating that it was downloaded from the internet, Word will enable Protected View.

There is a difference between launching a Microsoft Office application from Internet Explorer or another browser. With third-party browsers such as Chrome or Firefox, opening a document from a web page involves first saving the file locally with the appropriate MOTW and then opening that file with the associated application. The MOTW is preserved and the Office application will use Protected View as necessary.

However, with Internet Explorer, the associated Office application is launched via DCOM as shown in the screenshot below. When the UAC is disabled, opening a document from Internet Explorer (via DCOM) disables Protected View.

When the UAC is disabled, Internet Explorer does set the MOTW appropriately when the document is saved to the file system. This is consistent with the behavior of third-party web browsers. Opening the saved document with Office will use Protected View as expected, as shown in the screenshot below:

Conclusions and Recommendations

Since Microsoft states that "UAC elevations are conveniences and not security boundaries," it is important to realize the value of separate user accounts on a Windows system. Following this mindset, the UAC should not be trusted to restrict access to administrative privileges.

• Separate user accounts are a security boundary, and therefore the way to limit access to administrative privileges is to use a separate user account that does not have administrative privileges.
• Do not disable the UAC, as this action can affect a system in a way that is outside the scope of just integrity levels.
• Some applications may inconsistently respect MOTW and some may inconsistently apply the decisions that are made based on those markings. Specifically in the case of Microsoft Office and Adobe Flash, simply installing EMET 5.0 or later with the recommended settings will use Attack Surface Reduction (ASR) to block Flash from being used in Word, Excel, and PowerPoint.