New mitigation mechanisms in Windows 8.1

Earlier we wrote about some of the mechanisms of operational difficulties (mitigation) for Windows and applications that Microsoft was trying to bring with the release of new operating systems. As a rule, such mechanisms are based on the following conceptual approaches:

• Differentiation of application access rights to OS resources ( User Account Control , Integrity Level ). Vista +
• Special mitigating factors when working with DEP & ASLR memory. XP SP2 / Vista +. DEP is set by system settings and in Windows 8+ it is active for all applications (processor support). ASLR works for applications compiled with its support.
• Kernel ASLR / DEP, for components that operate in kernel mode. Vista SP1 +. ASLR / DEP is active by default for kernel-mode modules, DEP from executing data in the pool requires selections from NonPagedPoolNx (Windows 8+).
• Protection against rewriting pointers to functions in SEH at the OS level (SEHOP). Vista SP1 +. By default, it is active only for server editions.
• Free EMET tool (v 4.1 last update) to enhance the system’s immunity from exploit actions. For Windows XP +.
• Advanced isolation of AppContainer processes (aka sandboxing, advanced Integrity Level). Windows 8+. Used for Internet Explorer 10+ and all Modern UI aka Metro applications.
• Blocking access to obtaining information about the addresses of kernel objects for untrusted applications ( KASLR bypass mitigation ). Windows 8.1.

')

The last point deserves special attention, since this innovation was added by MS in Windows 8.1 as an extension for AppContainer mode or Integrity Level. Relatively speaking, the untrusted aka restricted caller application (whose Integrity Level < Medium ) does not have the right to obtain information about the addresses of various objects in the kernel mode, which means the actual compromise of the KASLR restrictions and the subsequent possible operation of the LPE (Local Privelege Escalation). The main functions of disclosing such information were of course NtQuerySystemInformation with various classes, as well as NtQueryProcessInformation . Access to the corresponding applications is limited to these functions.



In the case of NtQuerySystemInformation, the application with a low Integrity Level will be returned STATUS_ACCESS_DENIED if it requests information on the following classes:

• SystemModuleInformation / SystemModuleInformationEx - addresses of loaded drivers
• SystemLocksInformation - addresses of kernel objects (ERESOURCE)
• SystemStackTraceInformation - address of the kernel mode stack
• SystemHandleInformation / SystemExtendedHandleInformation - addresses of kernel objects
• SystemObjectInformation - addresses of kernel objects
• SystemBigPoolInformation / SystemSessionBigPoolInformation - allocated system memory addresses
• SystemProcessInformation / SystemExtendedProcessinformation / SystemFullProcessInformation - addresses of process kernel objects, streams and their stacks.

Fig. The call points of the Integrity Level check function in the application access token that is trying to access ntoskrnl! NtQuerySystemInformation . ntoskrnl! ExpQuerySystemInformation is responsible for collecting information for the corresponding classes, and the ntoskrnl! ExIsRestrictedCaller function is executed in it, which performs the check itself.



In addition to NtQuerySystemInformation, access is also blocked to the NtQueryInformationProcess function, through which the application can access the addresses of various objects. For the ProcessHandleTracing , ProcessWorkingSetWatch / ProcessWorkingSetWatchEx classes, the corresponding error status is also returned.



www.alex-ionescu.com/?p=82