CVE-2015-0016: Escaping the Internet Explorer Sandbox

Part of this January’s Patch Tuesday releases was MS15-004, which fixed a vulnerability that could be used in escalation of privilege attacks.

I analyzed this vulnerability (designated as CVE-2015-0016) because it may be the first vulnerability in the wild that showed the capability to escape the Internet Explorer sandbox. As sandboxing represents a key part of exploit mitigation techniques, any exploit that can break established sandboxes is worth a second look.

The vulnerability in the module TSWbPrxy.exe, which is an ActiveX Control. This module acts as the web proxy of the Microsoft Remote Desktop.

Patch differences

First, I used the IDA plugin patchdiff2 to see what modifications the patch had made. This was in the function CTSWebProxy::StartRemoteDestop.

Using OleView, I loaded TSWbPrxy.exe to see the definition of CTSWebProxy::StartRemoteDestop.

Figure 1. Definition of StartRemoteDesktop

I found that StartRemoteDesktop has two parameters, both related to mstsc.exe, which is the Remote Desktop application:

bstrMstsc: the file path of mstsc.exe
bstrArguments: the parameters of mstsc.exe

The StartRemoteDesktop function creates a process to launch mstsc.exe. I used the IDA plugins to show more clearly the differences between the patched and unpatched versions:

Figure 2. Differences between patched and unpatched versions
(Click to enlarge)

On the left is the patched version of this procedure. On the right is the unpatched version. On the patched version, before the call for CreateProcessW is carried out, check_path (shown in grey) is called. No such call exists on the unpatched version.

Let’s look at this particular function:

Figures 3 and 4. Code of check_path

It has one parameter (lpApplicationName) and performs the following routines:

First check lpApplicationName length. It this is bigger than 0x104, return error 0x80075007.
Format lpApplicationName, convert char ‘/’ to char ‘\’ and save the result to var_formatApplicationNmae.
call CompareStringW to compare the string SystemDirectory + “mstsc.exe” with the string var_formatApplicationNmae. If the two are equal, check_path returns 0.
call CompareStringW to compare the string SystemWow64Directory + “mstsc.exe” with var_formatApplicationNmae. If the two are equal, check_path returns 0 otherwise it returns error 0x80075007.

This allows us to see just how Microsoft patched the vulnerability. It checks if lpApplicationName is equivalent to the full path of the Remote Desktop application if it’s located in the System directory (which is C:\Windows\System32 for the 32-bit version and C:\Windows\SysWOW64 for the 64-bit version). If these two match, the process is created, otherwise an error is returned.

The root cause of the vulnerability is simple: the correct purpose of the StartRemoteDesktop function is to launch the Remote Desktop application, mstsc.exe. However, when the programmer implemented this function checking of the lpApplicationName parameter was not implemented. This means that the function can be used to launch arbitrary processes if the parameter lpApplicationName is modified.

Below is the code for the unpatched version:

Figure 5. Unpatched code

Escaping the Internet Explorer sandbox

In order to escape the Internet Explorer sandbox, we first need to see how sandbox elevation polices are implemented. Elevation polices determine how a process or a COM server will be launched, and with what privilege level. These are stored in registry keys under:

HKLM\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\{GUID}

Each registry key has the following values under it:

AppName: Application executable name
AppPath: Application path
Policy: this value specifies the privilege level of the executable, and can be any of the following values:

Figure 6. Varying policy settings

We will look at processes with the Policy value of 3. At this level, the Internet Explorer sandbox silently launches an application as a medium integrity process under the Internet Explorer broker process.

One such file is TSWbPryx.exe, the ActiveX control tied to MS15-004.

Figure 7. Settings in Windows Registry for TSWbPryx.exe

If an attacker can use a separate vulnerability to obtain a low integrity process within the sandbox, they can use the TSWbPrxy ActiveX control to call StartRemoteDesktop. This will launch an application (chosen by the attacker) with medium integrity, like its parent process TSWbPrxy.exe.

We can combine this vulnerability with CVE-2014-6332 (which we’ve previously analyzed)to do this. Combined, we can escape the Internet Explorer sandbox and can run an app with medium integrity.

In addition, used correctly CVE-2014-6332 can be used to bypass ActiveX security mechanisms. This will allow Internet Explorer to run these controls without a dialog (like the one below) being shown to the user:

Figure 8. ActiveX control alert

The end result will be an attacker able to run their specified application with medium integrity, as seen in the screenshot below.

Figure 9. Calculator being run with medium integrity

Solutions and Recommendations

While this vulnerability could pose a risk used with other vulnerabilities, it’s worth noting that Microsoft has already patched these issues as part of their regular Patch Tuesday cycles. Users with up-to-date systems would not be at risk, and neither would users of other browsers.

In addition, thee enhanced sandbox mentioned in this blog post is not present in older versions of Windows, such as Windows 7. While it can be bypassed (with effort), it is still an effective method to protect against many attacks. Using newer versions of Windows and Internet Explorer allows for improved exploit mitigation techniques to be used.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

CVE-2015-0016: Escaping the Internet Explorer Sandbox