Windows 7 Jan./Feb. 2018 patches opens Total Meltdown vulnerability

[German]It seems that things went terribly wrong. Microsoft's Meltdown updates shipped in January 2018 and February for Windows 7 (and Server 2008 R2) intended to mitigate the Meltdown vulnerability rip open a huge security hole. This allows any process under Windows 7 to read and write to any memory area without exploits.

The Meltdown vulnerability

At the turn from 2017 to 2018 vulnerabilities named Meltdown and Spectre on (Intel) CPUs became public. These vulnerabilities allow non-privileged (application) processes to access information in the memory (see link list at the end of the article). 

Software vendors tried hectically to mitigate these vulnerabilities with emergency updates. Microsoft also pushed some updates to its Windows machines in January 2018 to mitigate meltdown (see link list at the end of the article). But they made a fatal mistake and opened a huge security hole in Windows kernel. This security hole allowed each process to read the complete memory content (with capacities of gigabytes per second), and it was also possible to write to any memory addresses.

No exploit was needed to read or manipulate memory areas, because Windows 7 includede the possibility to access any required memory in every running process (also user processes). The utilization only required simple read and write operations on the already mapped virtual memory. Ulf Frisk points this out in the blog entry Total Meltdown?

Some details

Ulf Frisk describes within his blog post Total Meltdown?, that the User/Supervisor permission bit was set to User in the PML4 self-referencing entry. As a result, the page tables were available to the user mode code in each process. The page tables should normally only be accessible by the kernel itself.

(Source: Ulf Frisk)

Ulf provided a tiny program pcileech, that could be use to teste that behavior in console (see screenshot above).

In brief: Windows manages memory access via a Page Memory List (the PML4), which also controls which process can access which memory. The PML4 is the basis of the 4-level in-memory page table hierarchy. With this, the CPU Memory Management Unit (MMU) translates the virtual addresses of a process into physical memory addresses in RAM. For more information on paging, see Getting Physical: Extreme abuse of Intel based Paging Systems – Part 1 und Part 2.

Windows has a special entry in this top PML4 page table that references itself. The problem: In Windows 7 the PML4 self-referencing is at position 0x1ED, offset 0xF68 (only in Windows 10 the position of the entry is randomized). This means that the PML4 is always mapped to the address: 0xFFFFFFFFF6FB7DBED000 in the virtual memory. This is usually a memory address that is only made available to the kernel (supervisor).

Unfortunately, an accident happened in the January 2018 patch (and also in February 2018 patch) when the authorization bit was wrongly set to User. This caused the PML4 to appear in each process and be made available for the execution of code in user mode.

If a (user) process has read/write access to the page tables, it is trivially to access the entire physical memory. The only exception is storage, which is additionally protected by Extended Page Tables (EPTs) used for virtualization. All you have to do is write your own page table entries (PTEs) to the page tables to access any physical memory, says Ulf Frisk.

Toolkit for tests

Ulf Frisk released the PCILeech direct memory access attack toolkit on GitHub. He describes here how to use the pcileech.exe dump command to access the memory. But I wasn't able to manage that program, all I got, was some parameter reference.

Only Windows 7 x64 systems (and of course Windows Server 2008 R2) that were patched with the January and February 2018 updates are vulnerable. The March 2018 update for Windows 7 closes this security issue. But there are other problems with this update (Security Updates for Windows 7/8.1 (March 13, 2018)).

Frisk discovered this vulnerability shortly after the updates were installed on patch Tuesday in March 2018. But he writes that he was unable to correlate the vulnerability with known CVEs or other known problems.

Similar articles:
Critical Security Updates for Windows 7/8.1/Server (01/03/2018)
Security Updates for Windows 7/8.1 (March 13, 2018)
Meltdown and Spectre: What Windows users need to know
Meltdown/Spectre Test Tools Overview