Windows Kernel 64-bit stack memory disclosure in nt!NtQueryVirtualMemory (Memory(Privileged)BasicInformation)

Authors:Google Security Research   Risk:Medium

CVE:CVE-2018-0974                 0day:Information Disclosure

0day-id:0DAY-0974                  Date:2018-04-19

Description

An information disclosure vulnerability exists in the Windows kernel that could allow an attacker to retrieve information that could lead to a Kernel Address Space Layout Randomization (ASLR) bypass. An attacker who successfully exploited the vulnerability could retrieve the memory address of a kernel object.

To exploit the vulnerability, an attacker would have to log on to an affected system and run a specially crafted application.

The security update addresses the vulnerability by correcting how the Windows kernel handles memory addresses.

Analysis

We have discovered that the nt!NtQueryVirtualMemory system call invoked with the MemoryBasicInformation (0x0) and MemoryPrivilegedBasicInformation (0x8) information classes discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.

Both information classes appear to return the same output structure, MEMORY_BASIC_INFORMATION:

--- cut ---
  typedef struct _MEMORY_BASIC_INFORMATION {
    PVOID  BaseAddress;
    PVOID  AllocationBase;
    DWORD  AllocationProtect;
    SIZE_T RegionSize;
    DWORD  State;
    DWORD  Protect;
    DWORD  Type;
  } MEMORY_BASIC_INFORMATION, *PMEMORY_BASIC_INFORMATION;
--- cut ---

On x64 builds, the compiler introduces 4 bytes of padding between the “AllocationProtect” and “RegionSize” fields, in order to align the latter to an 8-byte boundary. Furthermore, 4 extra unused bytes are also added at the end of the structure, in order to align its size to an 8-byte boundary. None of these 8 unused bytes are initialized in the kernel’s local copy of the structure, and so they are returned to the user-mode caller in this undefined form.

The problem is best illustrated by running the attached proof-of-concept program, which sprays the kernel stack with a 0x41 (‘A’) marker byte, invokes the nt!NtQueryVirtualMemory syscall with the affected information classes, and prints the contents of the output buffer on the screen. The result of running it in our test Windows 10 environment is as follows:

--- cut ---
  ---------- MemoryBasicInformation Status: 0, Return Length: 30
  00000000: 00 00 58 3d f6 7f 00 00 00 00 58 3d f6 7f 00 00 ..X=......X=....
  00000010: 80 00 00 00 41 41 41 41 00 10 00 00 00 00 00 00 ....AAAA........
  00000020: 00 10 00 00 02 00 00 00 00 00 00 01 41 41 41 41 ............AAAA
  ---------- MemoryPrivilegedBasicInformation Status: 0, Return Length: 30
  00000000: 00 00 58 3d f6 7f 00 00 00 00 58 3d f6 7f 00 00 ..X=......X=....
  00000010: 80 00 00 00 41 41 41 41 00 10 00 00 00 00 00 00 ....AAAA........
  00000020: 00 10 00 00 02 00 00 00 00 00 00 01 41 41 41 41 ............AAAA
--- cut ---

It is clearly visible that in both cases, the bytes returned at offsets 0x14-0x17 and 0x2c-0x2f originate from an uninitialized kernel stack region. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public.

Acknowledgements

Mateusz Jurczyk of Google Project Zero

Leave a Reply