Windows Kernel 64-bit stack memory disclosure in nt!NtQuerySystemInformation (SystemPageFileInformation(Ex))

Authors:Google Security Research   Risk:Medium

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

0day-id:0DAY-0971                  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!NtQuerySystemInformation system call invoked with the SystemPageFileInformation (0x12) and SystemPageFileInformationEx (0x90) information classes discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.

Based on the contents of the output structure returned by the kernel, we have concluded that it contains a nested UNICODE_STRING structure at offset 0x10, which has the following definition:

--- cut ---
  typedef struct _LSA_UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;
  } UNICODE_STRING, *PUNICODE_STRING;
--- cut ---

On x64 builds, the compiler introduces 4 bytes of padding between the “MaximumLength” and “Buffer” fields, in order to align the “Buffer” pointer to an 8-byte boundary. It seems that these padding bytes are never initialized in the kernel’s local copy of the structure, and so they are returned to the user-mode caller in this 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!NtQuerySystemInformation 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 ---
  ---------- SystemPageFileInformation Status: 0, Return Length: 48
  00000000: 00 00 00 00 00 c0 02 00 00 00 00 00 01 01 00 00 ................
  00000010: 26 00 28 00 41 41 41 41 a0 fe 38 5c cc 00 00 00 &.(.AAAA..8\....
  00000020: 5c 00 3f 00 3f 00 5c 00 43 00 3a 00 5c 00 70 00 \.?.?.\.C.:.\.p.
  00000030: 61 00 67 00 65 00 66 00 69 00 6c 00 65 00 2e 00 a.g.e.f.i.l.e...
  00000040: 73 00 79 00 73 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? s.y.s...........
  ---------- SystemPageFileInformationEx Status: 0, Return Length: 50
  00000000: 00 00 00 00 00 c0 02 00 00 00 00 00 01 01 00 00 ................
  00000010: 26 00 28 00 41 41 41 41 a8 fe 38 5c cc 00 00 00 &.(.AAAA..8\....
  00000020: 00 c0 02 00 3f c1 13 00 5c 00 3f 00 3f 00 5c 00 ....?...\.?.?.\.
  00000030: 43 00 3a 00 5c 00 70 00 61 00 67 00 65 00 66 00 C.:.\.p.a.g.e.f.
  00000040: 69 00 6c 00 65 00 2e 00 73 00 79 00 73 00 00 00 i.l.e...s.y.s...
--- cut ---

It is clearly visible that in both cases, 4 bytes returned at offsets 0x14-0x17 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