{"id":11244,"date":"2018-01-25T20:41:13","date_gmt":"2018-01-26T04:41:13","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2018\/01\/25\/news-5015\/"},"modified":"2018-01-25T20:41:13","modified_gmt":"2018-01-26T04:41:13","slug":"news-5015","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2018\/01\/25\/news-5015\/","title":{"rendered":"A Deep Dive Analysis of Microsoft\u2019s Kernel Virtual Address Shadow Feature"},"content":{"rendered":"

Credit to Author: Minh Tran| Date: Thu, 25 Jan 2018 19:05:59 +0000<\/strong><\/p>\n

\n

 <\/p>\n

\n

\"\"<\/p>\n<\/p><\/div>\n

Introduction<\/h1>\n

The story involving Meltdown<\/a> and Spectre<\/a> continues as vendors (including major players like Apple<\/a> Oracle<\/a>, and Microsoft<\/a>, among others ) scramble to issue patches for their products. Even Intel’s own patches<\/a> have hidden problems that have led to higher-than-expected reboot rates, and these problems extend all the way from Sandy Bridge (2011) to Kaby Lake (2016).<\/p>\n

In a previous blog post<\/a>, FortiGuard Labs detailed the implementation of Spectre, and in another we provided a technical analysis<\/a> of Microsoft‘s patches (Microsoft Security Advisory ADV180002<\/a>). One of the key features of Microsoft‘s patches is the “Kernel Virtual Address Shadow” (a term coined by Microsoft), or KVAS for short. This feature effectively blocks the Meltdown attack, as it leaves very little kernel memory accessible to user mode code. In this blog post we provide a deep dive analysis of this feature.<\/p>\n

Overall Design<\/h1>\n

Before digging into the details, it’s worthwhile to understand the overall context. The following table summarizes the Spectre and Meltdown attacks:<\/p>\n

 <\/p>\n

\"\"<\/p>\n

Figure 1 Executive Summary (credits go to CERT<\/a>)<\/p>\n

As we can see, the difficulty of mounting a Meltdown attack is low (i.e. low cost) hence the chance of it being exploited in the real world scenarios will be high, as evidenced by the AV-Test research team’s discovery of 119 new malicious samples in just the two weeks following the disclosure of the vulnerability. As a result, it makes perfect sense for Microsoft to focus on defending against that attack first.<\/p>\n

Before delving into the details, we wrote this piece assuming that readers already possess a strong knowledge of low level system concepts and mechanisms such as virtual memory, 32-bit (aka x86) vs 64-bit (aka x64), MSR, kernel-mode vs user-mode, and so on. For details about those concepts and mechanisms, the Intel® 64 and IA-32 Architectures Software Developer's Manuals are the authoritative resources. Providing a primer on those concepts is beyond the scope of this paper, and we recommend that those unfamiliar with these details to start there.<\/p>\n

\"\"<\/p>\n

Figure 2 The Overall Design<\/p>\n

Figure 2 depicts the overall idea behind KVAS. Conceptually speaking, the system is partitioned into three parts: the entries, arbitrary control flow in the middle, and the exits. The key insight here is that the kernel space and the user space are separated thanks to clever paging structures. Only a minimal numbers of pages are mapped in both the user space and the kernel space. As a result, even if a Meltdown attack were to be successful, it still could not leak kernel memory. That’s because the entries and the exits swap address spaces back and forth such that only the kernel code can access kernel memory space. An extra benefit of this design is that it achieves its goal simply by manipulating the paging structures without having to rely on any extra support at the hardware level (e.g. microcode updates)<\/p>\n

\"\"<\/p>\n

Figure 3 NtOpenProcess Is Not Accessible<\/p>\n

As can be seen in figure 3, the code region of NtOpenProcess<\/strong> is not accessible because it is not mapped using UserDirectoryTableBase<\/strong>.<\/p>\n

Analysis of The Implementation<\/h1>\n

This section highlights key findings of our analysis of the Kernel VA Shadow Feature (KVAS). Here are the key details of the NT Kernel itself:<\/p>\n

Windows 7 x64: 6.1.7601.24000<\/p>\n

Size: 5581544 bytes<\/p>\n

Sha256: 9A6C19B29EBB8D9399C771F2B570E6DCDDF75AC7F2A5F4E8013F4EC7A31F7CA8<\/p>\n

We found that KVAS is initialized very early in the boot process. Specifically, KVAS is enabled in the OS initialization itself. The entry point of the NT Kernel is called KiSystemStartup, <\/strong>and is invoked by the OS loader. KiSystemStartup <\/strong>in turn performs basic initialization of several things, one of which is the calling of KiInitializeBootStructures<\/strong>.<\/strong><\/p>\n

\"\"<\/p>\n

Figure 4 KiInitializeBootStructures<\/p>\n

KiInitializeBootStructures<\/strong> in turn calls KiEnableKvaShadowing<\/strong>, which is responsible for enabling KVAS and sets KiKvaShadow<\/strong> = 1.<\/p>\n

\"\"<\/p>\n

Figure 5 KiEnableKvaShadowing<\/p>\n

We also observed that based on process-context identifiers (PCID – which is a performance optimization feature to avoid flushing the entire translation lookaside buffer), the global flag KiKvaShadowMode<\/strong> will be set accordingly to either 1 (KiFlushPcid<\/strong> != 0) or 2 (KiFlushPcid<\/strong> == 0).<\/p>\n

\"\"<\/p>\n

Figure 6 KiKvaShadow and PCID<\/p>\n

The key part of the whole process is the setting up of the system call handlers themselves.<\/p>\n

\"\"<\/p>\n

Figure 7 Setting Up of the System Call Handlers<\/p>\n

But first, a quick primer about the mechanism used to perform system calls. When the SYSCALL instructions are executed (e.g. in ntdll.dll<\/strong>), the code execution is switched to a kernel-mode routine whose address is pointed to by a Model Specific Register (MSR). MSRs are special registers that must be accessed through rdmsr<\/strong> and wrmsr<\/strong> CPU instructions using indices. For example, the index for IA32_STAR<\/strong> is C0000081 and IA32_LSTAR<\/strong> is C0000082 and so on.<\/p>\n