Usermode Sandboxing

User mode Sandboxing

A lot of people (including myself, until recently) think that effective sandboxing requires a filter driver or kernel hooking, but this is no longer the case. A new security feature introduced in Windows Vista known as the Windows Integrity Mechanism can be used to create sandboxes that run entirely in usermode. Although the mechanism was not designed to be used this way, it makes for great driverless sandboxing.

The Windows Integrity Mechanism

Similar to User Account Contorl (UAC), the Windows Integrity Mechanism allows the system to restricted applications from accessing certain resources; however, it’s more defined than simply elevated/unelevated. There are 4 main levels provided, which can be set by a parent process prior to execution.

System Integrity (Mandatory LabelSystem Mandatory Level)
This is the highest integrity level and is used by processes and services running under the Local Service, Network Service, and System account. The purpose of this level is to provide a security layer between Administrator and System, even a process running as full Administrator cannot interact with with System integrity level processes (The only exception to this rule is if the administrator account is granted SE_DEBUG_NAME privilege, then the process can enables this privilege in its token to interact with processes across integrity and user boundaries).


High Integrity (Mandatory LabelHigh Mandatory Level)
The default integrity level assigned to processes running under the Administrator account, if User Account Control is enabled this level will only be given to elevated processes.

Medium Integrity (Mandatory LabelMedium Mandatory Level)
Given to processes running under a limited (non-Administrator) user account or processes on an Administrator account with UAC enabled. Processes assigned this integrity level can only modify HKEY_CURRENT_USER registry keys, files in non protected folders, and processes with the same or lower integrity.

Low Integrity (Mandatory LabelLow Mandatory Level)
The lowest integrity level is not assigned to processes by default, it is either assigned through inheritance (given to processes created by other low integrity processes) or set by the parent process. A process running with low integrity level can only create/modify keys under HKEY_CURRENT_USERSoftwareAppDataLow and write files to %USER PROFILE%AppDataLocalLow. It is practically impossible for a low integrity process to make any changes to the system; However, it can still read most data.

The windows integrity mechanism has a strict set of rules which makes it a nice system for process isolation (when used properly).

·         A process cannot change its own integrity level.

·         Once a process is running, the integrity level cannot be changed (even by a higher integrity process).

·         A process can create processes with the same (or lower) integrity level, but not higher.

·         Processes cannot modify/write processes/files with a higher integrity level.

There are a few (fairly low risk) exceptions to the above rules.

·         A high integrity process granted SE_DEBUG_NAME can modify processes of higher integrity level. 

·         A medium integrity process that is signed by Microsoft can elevate some COM objects from medium to high integrity (this is what gets leveraged by the auto-elevated process UAC exploit).

·         A process can request elevation from medium to high integrity, but only on execution (spawns UAC prompt). 

Communication between a low and higher integrity process (IPC) is possible when explicitly enabled by the higher integrity process. Any of the following methods can be used:

·         Shared Memory

·         Sockets

·         RPC

·         Windows Messages

·         Named Pipes

Usermode Sandboxing

In the past usermode sandboxes would inject a dll into sandboxed processes and hook various functions within ntdll, although this was generally quite effective, applications could escape the sandbox by reading ntdll from the disk and using it to restore the hooks. Now usermode hooks are making a comeback in sandboxing, but without the previous fallbacks.

Processes can be spawned as low integrity to preventthem making changes to the system; However, in order for the sandboxed process to continue functioning normally, it may need to make some (limited) changes to the system, this is where the hooks come in. 

The sandbox creates a broker process which runs with a normal integrity level, this process then uses CreateProcessAsUser to spawn the target (sandboxed) process at low integrity. Before the target process begins execution, the sandbox dll is loaded and hooks ntdll so the hooks can be used to pass information about any calls (target function, parameter addresses, number of parameters) to the broker process via IPC. The broker process will read the parameters from the sandboxed process and filter/process calls on its behalf. Unlike with previous usermode sandboxes, removal of the hooks will result in the process not being able to modify system resources as it requires the broker process to do so on its behalf. 

This type of sandboxing is already used by some applications (Such as Chrome, Internet Explorer, and Flash Player) to reduce the attack surface for exploits. Low integrity processes are used for processing and handling of untrusted data such as javascript or flash (As a result an exploit would first have to exploit the low integrity process and then exploit the sandbox process to gain full execution on the system).  

For malware sandboxing, things are a bit different: Because low integrity processes can still manipulate other low integrity processes (most browsers run as low integrity), sandboxed malware would still be able to inject into a browser process and pass data back to a command and control server. Low integrity processes are also not very restricted in terms of reading data and could log documents and program data. To protect malware from injecting into browsers or reading personal documents, it would be possible to run the sandboxed and broker process under a different user account (CreateProcessAsUser), aslLow and medium integrity processes cannot read documents from other user’s directories or interact with processes across user boundaries; However, they could still read from Program Files and System32. 

Conclusion

Although the Windows Integrity Mechanism is by no means perfect for malware sandboxing, it is definitely a considerable alternative to maintaining complex filter drivers and paying for code signing certificates. Windows 8 even introduces a new features, AppContainer, which nicely complements the Windows Integrity Mechanism by allowing processes to be restricting to only reading and writing within their install folder. If Microsoft could just manage to stop making Fisher Price user interfaces for one operating system, we may see anti-malware sandboxes shifting to usermode as people move away from Windows 7.