Introduction

2018 truly is starting off with a bang: fundamental CPU flaws dubbed Meltdown and Spectre were found affecting pretty much all modern processors developed since the Pentium Pro (1995). These flaws root in two critical CPU features: Out of Order Execution and Speculative Execution, which are crucial for performance. Since this is an important feature and not a bug, it is inherently hard to fix. Furthermore, for performance reasons, speculative execution is almost always implemented in hardware, so “fixes” tend toward mitigations (e.g. microcode updates).

Due to the serious nature of these flaws, chip developers such as Intel, AMD, and ARM have had to issue an emergency press conference releases, and Intel has further promised to deliver “Firmware Updates for Most Modern CPUs by the End of Next Week.”

In the wake of these events, vendors who rely on this hardware have had to likewise scramble to issue mitigations for their products. Microsoft, for example, has gone out its way to issue emergency out-of-band patches, which are detailed in Microsoft Security Advisory ADV180002. Ever since the release of these patches, we at FortiGuard Labs have been hard at work analyzing them, and in this blog post we detail our results.

Everything You Always Wanted to Know About Meltdown (and Spectre) But Were Afraid to Ask

Before going into the details, it’s worthwhile to understand the context. The following table summarizes Spectre and Meltdown:

Figure 1 Executive Summary (credit goes to CERT)

At first first sight, it looks like Spectre and Meltdown are different attacks, but fundamentally speaking both rely on speculative execution and out of order execution, and both use CPU cache as a side channel. The technical details run deep, but the CERT report provides an excellent summary and can be read without a Ph.D. For daring readers who want to delve deeper, you can refer to the original academic papers of Meltdown and Spectre respectively.

CVEs:

Spectre attack: CVE-2017-5753, CVE-2017-5715

Meltdown attack: CVE-2017-5754

A Bird's Eye View of the Patches

In security advisory ADV180002, Microsoft provided patches for many of its products, but for this analysis we decided to focus on Windows 7 as it has the largest market share.

Figure 2 Operating System Share by Version

We obtained the patches in MSU format from Microsoft. The following table summarizes the patches:

It is rather interesting to see that the x64 patch (70194359 bytes) is so much bigger than the x86 patch (37908254 bytes). While the difference in the size of the data (e.g. pointer and integer from 32 bit to 64 bit) does account for some of the increase, it is definitely not responsible for that much, so we decided to dig deeper. Using custom tools we extracted the content of the patches, and from there we found the metadata, which in turn allowed us to know exactly which components were getting patched.

Figure 3 Metadata for Microsoft-Windows-OS-Kernel

The components that are common to both patches are:

Mcupdate

Microsoft-Windows-Os-Kernel

Microsoft-Windows-Com-Base-Qfe-Rpcss                

Microsoft-Windows-Kernel32

Microsoft-Windows-Kernelbase

Microsoft-Windows-Smb20-Minirdr

Microsoft-Windows-Filtermanager-Core

Microsoft-Windows-Gdi

Microsoft-Windows-Hal

Microsoft-Windows-Http

Microsoft-Windows-Win32k

etc.

The components that are unique to the x64 patch, however, are mainly Hyper-V, and Wow64:

Microsoft-Hyper-V-Drivers-Hypervisor

Microsoft-Hyper-V-Drivers-Vmswitch

Microsoft-Hyper-V-Vstack-Com

Microsoft-Hyper-V-Vstack-Vmms

Microsoft-Hyper-V-Vstack-Vmwp

etc.

Figure 4 Summary of the Patches

As can be seen, this table explains why the x64 patch is so much bigger. Given the sheer amount of changes, and in the interest of time, however, in the next section we will only focus on the Windows Kernel.

NT Kernel

Obviously, the NT Kernel is the most interesting component because it is central to the OS operations. This patch updates the Windows 7 Kernel to version 6.1.7601.24000. We are happy to report that Windows 7 x64 gets the all-important kernel VA shadow feature. This feature effectively blocks the Meltdown attack, as there is very little kernel memory accessible, as we shall show below.

Figure 5 Extensive Code Change for Kernel VA Shadow Feature

The key insight is that physical address space is now mapped differently for user-mode code and kernel-mode code. The page directory for user-mode code is UserDirectoryTableBase and for kernel-mode code is DirectoryTableBase. So even if the Meltdown attack were to be successful, it still cannot leak kernel memory. This, unfortunately, cannot protect against the Spectre attack as it is an orthogonal attack where the attacker tricks speculative executed instructions into leaking information that the victim process is already authorized to access.

Figure 6 Code Region of NtCreateFile is not Mapped

As can be seen in Figure 6, the code region of NtCreateFile is not accessible because it is not mapped using UserDirectoryTableBase but it is instead mapped using DirectoryTableBase. A short walkthrough of what the commands do is as follows:

• The 1st command (dt) displays the content of DirectoryTableBase and UserDirectoryTableBase
• The 2nd command (?) is used to evaluate an expression. In this case, it helps show the address of NtCreateFile (In WinDbg, nt is the standard way to refer to the NT kernel)
• The 3rd command (vtop) tries to translate a virtual address (NtCreateFile) to the corresponding physical address using DirectoryTableBase
• The 4th command (vtop) tries to achieve a similar goal but uses UserDirectoryTableBase

An astute reader may wonder, “so how does syscall happen?” Well, the answer is simple. The syscall handler (KiSystemCall64Shadow) is still mapped to route syscalls call as usual.

Figure 7 Code Region of KiSystemCall64Shadow is Indeed Mapped

As a final note, the 32-bit version of Windows, unfortunately, does not get blessed with this feature. There is no kernel VA shadow feature whatsoever. For further details on the reasons why, here is the latest Microsoft‘s official position as of the writing of this article:

Result

Security-wise, we have observed that these patches do address the uncovered security problems, although there seems to be an ongoing issue with AMD processors. Performance-wise, we sourced results from multiple high quality news outlets and show some representative results below:

Figure 8 Cinebench R15 (credits: TechSpot)

Figure 9 Excel 2016 (credits: TechSpot)

Figure 10 AS SSD Benchmark (credits: TechSpot)

Figure 11 (credits: TomsHardware)

Based on these results, the performance hit from these patches appears to be negligible except for SSD. And even then, TomsHardware puts it best when they say, “As of now, a 3.21% performance drop on an Intel Optane SSD 900P isn't the end of the world and isn't going to be noticeable with the majority of applications.”

Conclusion

Overall, the patches work and the performance trade-off is well worth the peace of mind.

To mitigate Meltdown and Spectre, organizations should follow guidance from vendors. A comprehensive list is being maintained by US-CERT.

For more information on this attack, and how to ensure your Fortinet products are properly protected, read our recent PSIRT notice.

As usual, FortiGuard Labs will continue to monitor the situation and provide additional updates as new information comes to light.

-= FortiGuard Lion Team =

Sign up for our weekly FortiGuard Labs intel briefs or to be a part of our open beta of Fortinet’s FortiGuard Threat Intelligence Service.