Processes, Threads, and Jobs in the Windows Operating System
- 6/17/2009
Protected Processes
In the Windows security model, any process running with a token containing the debug privilege (such as an administrator’s account) can request any access right that it desires to any other process running on the machine—for example, it can read and write arbitrary process memory, inject code, suspend and resume threads, and query information on other processes. Tools like Process Explorer and Task Manager need and request these access rights to provide their functionality to users.
This logical behavior (which helps ensure that administrators will always have full control of the running code on the system) clashes with the system behavior for digital rights management requirements imposed by the media industry on computer operating systems that need to support playback of advanced, high-quality digital content such as BluRay and HD-DVD media. To support reliable and protected playback of such content, Windows uses protected processes. These processes exist alongside normal Windows processes, but they add significant constraints to the access rights that other processes on the system (even when running with administrative privileges) can request.
Protected processes can be created by any application; however, the operating system will only allow a process to be protected if the image file has been digitally signed with a special Windows Media Certificate. The Protected Media Path (PMP) in Windows Vista makes use of protected processes to provide protection for high-value media, and developers of applications such as DVD players can make use of protected processes by using the Media Foundation API.
The Audio Device Graph process (Audiodg.exe) is a protected process, since protected music content may be decoded through it. Similarly, the Windows Error Reporting (WER; see Chapter 3 for more information) client process (Werfault.exe) can also run protected because it needs to have access to protected processes in case one of them crashes. Finally, the System process itself is protected because some of the decryption information is generated by the Ksecdd.sys driver and stored in its user-mode memory. The System process is also protected to protect the integrity of all kernel handles (since the System process’s handle table contains all the kernel handles on the system).
At the kernel level, support for protected processes is twofold: first, the bulk of process creation occurs in kernel mode to avoid injection attacks. (The flow for both protected and standard process creation is described in detail in the next section.) Second, protected processes have a special bit set in their EPROCESS structure that modifies the behavior of security-related routines in the process manager to deny certain access rights that would normally be granted to administrators. Table 5-5 indicates access rights that are limited or denied.
Table 5-5. Process Access Rights Denied for Protected Processes
Object: Access Mask |
Function |
Standard: READ_CONTROL |
Prevents the protected process’s access control list (ACL) from being read. |
Standard: WRITE_DAC, WRITE_OWNER |
Prevents access to the protected process’s access control list or modifying its owner (which would grant the former). |
Process: PROCESS_ALL_ACCESS |
Prevents full access to the protected process. |
Process: PROCESS_CREATE_PROCESS |
Prevents creation of a child process of a protected process. |
Process: PROCESS_CREATE_THREAD |
Prevents creation of a thread inside a protected process. |
Process: PROCESS_DUP_HANDLE |
Prevents duplication of a handle owned by the protected process. |
Process: PROCESS_QUERY_INFORMATION |
Prevents querying all information on a protected process. However, a new access right was added, PROCESS_QUERY_LIMITED_INFORMATION, that grants limited access to information on the process. |
Process: PROCESS_SET_QUOTA |
Prevents setting memory or processor-usage limits on a protected process. |
Process: PROCESS_SET_INFORMATION |
Prevents modification of process settings for a protected process. |
Process: PROCESS_VM_OPERATION, PROCESS_VM_READ, PROCESS_VM_WRITE |
Prevents accessing the memory of a protected process. |
Certain access rights are also disabled for threads running inside protected processes; we will look at those access rights later in this chapter in the section Thread Internals.
Because Process Explorer uses standard user-mode Windows APIs to query information on process internals, it is unable to perform certain operations on such processes. On the other hand, a tool like WinDbg in kernel debugging mode, which uses kernel-mode infrastructure to obtain this information, will be able to display complete information. See the experiment in the thread internals section on how Process Explorer behaves when confronted with a protected process such as Audiodg.exe.
Limiting these access rights reliably allows the kernel to sandbox a protected process from user-mode access. On the other hand, because a protected process is indicated by a flag in the EPROCESS block, an administrator can still load a kernel-mode driver that disables this bit. However, this would be a violation of the PMP model and considered malicious, and such a driver would likely eventually be blocked from loading on a 64-bit system because the kernel-mode code-signing policy prohibits the digital signing of malicious code. Even on 32-bit systems, the driver has to be recognized by PMP policy or else the playback will be halted. This policy is implemented by Microsoft and not by any kernel detection. This block would require manual action from Microsoft to identify the signature as malicious and update the kernel.