The research describes TOCTOU (Time-Of-Check-to-Time-Of-Use) issues applicable to hooking of Windows system services. The hooking is typical approach used by various security products around. With the research I have published a sample exploit which does not target any particular product.

What is severity?
The vulnerability allows bypassing certain security restrictions enforced by 3d security software, such as anti-viruses, host intrusion preventions, firewalls and etc. The issue renders the products ineffective. However, it doesn't introduce additional threats, such as privilege escalation and so on.

Who is affected?
Many 3d party security products running 32-bit Windows platforms use hooking of Windows Services. To a certain extent all such products are vulnerable.

How easy it to exploit?
As was demonstrated in my research the exploit could be simple and stable particularly on multi-CPU/Core machines.

How to fix it?
In most of cases the issue cannot be properly fixed without removing system service hooking. The hooking should be replaced by device filtering, object and registry callbacks, various filter APIs and other means provided by Windows core. Virtually it means the affected security products should be partially re-designed. It takes quite a bit of time and cannot be done over night. So we may oversee vendors quickly claiming a fix but it likely would be just a workaround for particular attack vector, not a proper fix.

1. Access control checks according to integrity levels;
2. Standard access control for DACL;
3. Protected process checks.

Process/Thread specific checks are based on examining protection attribute for both acting and target processes.

The same access checks are applied for threads that belong to protected processes.

By default following processes are started as protected:

• System
• audiodg.exe
• mfpmp.exe
• WerFault.exe
• WerFaultSecure.exe
• wermgr.exe

Protected processes are started via CreateProcess, CreateProcessAsUser, CreateProcessWithToken, etc. APIs by supplying CREATE_PROTECTED_PROCESS flag in CreationFlags parameter.

When the flag is specified system creates an executable section (ZwCreateSection) with SEC_PROTECTED_IMAGE flag which forces signature checking. If an executable has no specific signature CreateProcess returns ERROR_INVALID_IMAGE_HASH. The signature could be embedded or provided in installed catalog file. Additionally signature checking is performed for all DLLs loaded into protected process. It means Microsoft limits usage of protected processes by third parties. Protected Media Path program provides a way to supply signed modules for audiodg.exe and mfpmp.exe processes.

The control over protected processes code is justified as a protected process may receive unrestricted access to other protected processes. Hence a custom protected processes with random code breaks the whole concept.

The purpose of protected processes is not only providing environment for DRM solutions but also protecting kernel integrity. System process contains kernel mode threads and handles for many critical objects. For example, an unrestricted access to System process would effectively diminish kernel protection (aka Driver Signing) in Windows Vista x64.

Apparently there are other applications which could be started protected beside the listed above. For example, Microsoft Debugging Tools contain few utilities which may start as protected. You may find such applications by pplauncher.exe tool. The tool just probes for protected process launching by legitimate means, it does not use drivers and might run without administrative privileges. Do not mix it up with Alex Ionescu's tool that based on modification of kernel structures.

Note protection attribute is a part of EPROCESS structure and could be adjusted by kernel mode driver or debugger, which is illustrated by following experiment with Windows Task Manager.

Initially TaskManager is not protected and as result cannot create memory dump of protected processes.

Dumping EPROCESS structure in debugger reveals ProtectedProcess bit flag:

kd> dt _EPROCESS 8bb8a020
...
+0x14c ImageFileName : [16] "taskmgr.exe"
...
+0x224 Flags2 : 0xd000
+0x224 JobNotReallyActive : 0y0
+0x224 AccountingFolded : 0y0
+0x224 NewProcessReported : 0y0
+0x224 ExitProcessReported : 0y0
+0x224 ReportCommitChanges : 0y0
+0x224 LastReportMemory : 0y0
+0x224 ReportPhysicalPageChanges : 0y0
+0x224 HandleTableRundown : 0y0
+0x224 NeedsHandleRundown : 0y0
+0x224 RefTraceEnabled : 0y0
+0x224 NumaAware : 0y0
+0x224 ProtectedProcess : 0y0
+0x224 DefaultPagePriority : 0y101
+0x224 PrimaryTokenFrozen : 0y1
+0x224 ProcessVerifierTarget : 0y0
+0x224 StackRandomizationDisabled : 0y0
+0x228 Flags : 0x144d0801
...

Modification of the flag makes TaskManager a protected process.

kd> ed 8bb8a020+224 0xd800
kd> dt _EPROCESS 8bb8a020
...
+0x14c ImageFileName : [16] "taskmgr.exe"
...
+0x224 ProtectedProcess : 0y1
...

The flag modification is used by Alex Ionescu's tool.

ABSTRACT
Windows access control evolves from the original model to address actual security threats. In overall it becomes more and more complicated. Starting from Windows Vista, access control shifts towards mandatory access control (MAC). The shift is used to mitigate weaknesses of discretional access control (DAC) that relies upon user's settings. This paper discusses the main weaknesses of discretional access control such as privilege elevation through impersonation, complexity of configuration, ownership specific and uncontrollable objects. Then it describes how the issues partly resolved by new mandatory access control model also known as integrity levels. The main focus is given to the least privileges concept or so called "security boundary" that could be achieved by the combination of access control lists and integrity levels. Security boundary is required to reduce attack surface, damage caused by malware and targeted intrusions. While the recent access control developments help to enforce a real security boundary around untrusted applications, they have a number of described usage limitations. Finally, the paper concludes general inadequacy of discretional user based access control and advocates for true per-process permissions. As per-process permissions apparently are too complicated for a human administrator to configure properly, a solution is proposed addressing the complexity problem.