We have discovered that the nt!NtQueryInformationThread system call invoked with the 0 information class (ThreadBasicInformation) discloses portions of uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10. The specific layout of the corresponding output buffer is unknown to us; however, we have determined that the output size is 48 bytes. At offset 4 of the data, 4 uninitialized bytes from the kernel stack are leaked to the client application. This is most likely caused by compiler-introduced alignment between the first and second field of the structure (4-byte and 8-byte long, respectively). This would also explain why the leak does not manifest itself on x86 builds, as the second field is 4-byte long and therefore must be aligned to 4 instead of 8 bytes. The attached proof-of-concept program demonstrates the disclosure by spraying the kernel stack with a large number of 0x41 ('A') marker bytes, and then calling the...
We have discovered that the nt!NtQueryInformationThread system call invoked with the 0 information class (ThreadBasicInformation) discloses portions of uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10. The specific layout of the corresponding output buffer is unknown to us; however, we have determined that the output size is 48 bytes. At offset 4 of the data, 4 uninitialized bytes from the kernel stack are leaked to the client application. This is most likely caused by compiler-introduced alignment between the first and second field of the structure (4-byte and 8-byte long, respectively). This would also explain why the leak does not manifest itself on x86 builds, as the second field is 4-byte long and therefore must be aligned to 4 instead of 8 bytes. The attached proof-of-concept program demonstrates the disclosure by spraying the kernel stack with a large number of 0x41 ('A') marker bytes, and then calling the affected system call. An example output is as follows: ``` 00000000: 03 01 00 00 41 41 41 41 00 a0 10 2c f2 00 00 00 ....AAAA...,.... 00000010: 90 1b 00 00 00 00 00 00 1c 3a 00 00 00 00 00 00 .........:...... 00000020: ff 0f 00 00 00 00 00 00 09 00 00 00 00 00 00 00 ................ ``` It is clearly visible here that 4 bytes copied from ring-0 to ring-3 remained uninitialized. If the stack spraying function call is commented out, the top 32 bits of raw kernel pointers can be observed in the output. 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.
