We have discovered that it is possible to disclose portions of uninitialized kernel stack memory to user-mode applications in Windows 7-10 through the win32k!NtGdiGetRealizationInfo system call.
The concrete layout of the input/output structure is unclear (symbols indicate its name is FONT_REALIZATION_INFO), but the first DWORD field contains the structure size, which can be either 16 or 24. The internal win32k!GreGetRealizationInfo function then initializes a local copy of the structure on the kernel stack with an adequate number of bytes. However, the syscall handler later copies the full 24 bytes of memory back to user-mode, regardless of the declared size of the structure, and the number of bytes initialized within it:
--- cut ---
.text:BF86F307 mov edi, ecx
.text:BF86F309
.text:BF86F309 loc_BF86F309:
.text:BF86F309 push 6
.text:BF86F30B pop ecx
.text:BF86F30C lea esi, [ebp+var_30]
.text:BF86F30F rep movsd
--- cut ---
In other words, if we pass in a structure with .Size set to 16, the kernel will leak 8 uninitialized stack bytes back to us. This condition is illustrated by the attached proof-of-concept program, which first sprays 1024 bytes of the kernel stack with the 0x41 ('A') value, and then invokes the affected system call. The result of starting the program on Windows 7 32-bit is as follows:
--- cut ---
00000000: 10 00 00 00 03 01 00 00 2d 00 00 00 65 00 00 46 ........-...e..F
00000010: 41 41 41 41 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? AAAAAAAA........
--- cut ---
It is clearly visible that the 8 trailing bytes are set to the leftover 'A's artificially set up to demonstrate the security issue.
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.
