VULHUB ™

We have discovered a Windows kernel memory disclosure vulnerability through the body of "AllocConfig" registry values (of type REG_RESOURCE_LIST), which can be found under HKLM\SYSTEM\CurrentControlSet\Enum\*\*\*\Control\AllocConfig. The vulnerability affects 64-bit versions of Windows 7 to 10. The leak was originally detected under the following stack trace (Windows 7): ``` kd> k # Child-SP RetAddr Call Site 00 fffff880`020a68a8 fffff800`0295bdaa nt!memcpy+0x3 01 fffff880`020a68b0 fffff800`0295c30f nt!CmpQueryKeyValueData+0xea 02 fffff880`020a6940 fffff800`0296107f nt!CmQueryValueKey+0x1af 03 fffff880`020a6a20 fffff800`0268d093 nt!NtQueryValueKey+0x37d 04 fffff880`020a6bb0 00000000`772abeaa nt!KiSystemServiceCopyEnd+0x13 05 00000000`007aeb18 00000000`77153dec ntdll!ZwQueryValueKey+0xa 06 00000000`007aeb20 00000000`77153ff2 kernel32!LocalBaseRegQueryValue+0x17c 07 00000000`007aeca0 000007fe`fc281dd1 kernel32!RegQueryValueExW+0xf2 08 00000000`007aed40 000007fe`fc2735e4...

We have discovered a Windows kernel memory disclosure vulnerability through the body of "AllocConfig" registry values (of type REG_RESOURCE_LIST), which can be found under HKLM\SYSTEM\CurrentControlSet\Enum\*\*\*\Control\AllocConfig. The vulnerability affects 64-bit versions of Windows 7 to 10. The leak was originally detected under the following stack trace (Windows 7): ``` kd> k # Child-SP RetAddr Call Site 00 fffff880`020a68a8 fffff800`0295bdaa nt!memcpy+0x3 01 fffff880`020a68b0 fffff800`0295c30f nt!CmpQueryKeyValueData+0xea 02 fffff880`020a6940 fffff800`0296107f nt!CmQueryValueKey+0x1af 03 fffff880`020a6a20 fffff800`0268d093 nt!NtQueryValueKey+0x37d 04 fffff880`020a6bb0 00000000`772abeaa nt!KiSystemServiceCopyEnd+0x13 05 00000000`007aeb18 00000000`77153dec ntdll!ZwQueryValueKey+0xa 06 00000000`007aeb20 00000000`77153ff2 kernel32!LocalBaseRegQueryValue+0x17c 07 00000000`007aeca0 000007fe`fc281dd1 kernel32!RegQueryValueExW+0xf2 08 00000000`007aed40 000007fe`fc2735e4 umpnpmgr!OpenLogConfKey+0xb3 09 00000000`007aedc0 000007fe`ff25e9d5 umpnpmgr!PNP_GetFirstLogConf+0x8d [...] ``` and more specifically in the copying of the CM_RESOURCE_LIST structure: ``` kd> db rdx rdx+r8-1 fffff8a0`049d5bd4 01 00 00 00 05 00 00 00-00 00 00 00 01 00 01 00 ................ fffff8a0`049d5be4 05 00 00 00 03 01 80 00-00 00 00 c0 00 00 00 00 ................ fffff8a0`049d5bf4 00 00 02 00 00 00 00 00-81 01 00 00 01 00 00 00 ................ fffff8a0`049d5c04 00 00 00 00 00 00 00 00-aa aa aa aa 01 01 31 01 ..............1. fffff8a0`049d5c14 40 c0 00 00 00 00 00 00-40 00 00 00 00 00 00 00 @.......@....... fffff8a0`049d5c24 81 01 00 00 01 00 00 00-01 00 00 00 00 00 00 00 ................ fffff8a0`049d5c34 aa aa aa aa 02 03 00 00-05 00 00 00 05 00 00 00 ................ fffff8a0`049d5c44 ff ff ff ff 00 00 00 00 ........ ``` In the above example, the 0xaa values at offsets 0x38-0x3b and 0x60-0x63 are uninitialized bytes originating from a pool allocation made in nt!PnpBuildCmResourceList. If we dive deeper into the layout of the memory area, we can see that in both cases, the leaked bytes reside at the end of a nested CM_PARTIAL_RESOURCE_DESCRIPTOR structure: ``` kd> dt _CM_RESOURCE_LIST @rdx ntdll!_CM_RESOURCE_LIST +0x000 Count : 1 +0x004 List : [1] _CM_FULL_RESOURCE_DESCRIPTOR kd> dx -r1 ((ntdll!_CM_FULL_RESOURCE_DESCRIPTOR (*)[1])0xfffff8a0049d5bd8) ((ntdll!_CM_FULL_RESOURCE_DESCRIPTOR (*)[1])0xfffff8a0049d5bd8) : 0xfffff8a0049d5bd8 [Type: _CM_FULL_RESOURCE_DESCRIPTOR (*)[1]] [0] [Type: _CM_FULL_RESOURCE_DESCRIPTOR] kd> dx -r1 ((ntdll!_CM_FULL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5bd8) ((ntdll!_CM_FULL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5bd8) : 0xfffff8a0049d5bd8 [Type: _CM_FULL_RESOURCE_DESCRIPTOR *] [<Raw View>] [Type: _CM_FULL_RESOURCE_DESCRIPTOR] [0] : Memory Resource: 0xc0000000 of length 0x20000 [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR] [1] : Private Device Resource [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR] [2] : Port Resource: 0xc040 of length 0x40 [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR] [3] : Private Device Resource [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR] [4] : Interrupt Resource [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR] kd> dx -r1 ((ntdll!_CM_PARTIAL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5bfc) ((ntdll!_CM_PARTIAL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5bfc) : 0xfffff8a0049d5bfc : Private Device Resource [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR *] [<Raw View>] [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR] Type : 0x81 [Type: unsigned char] Flags : 0x0 kd> dx -r1 ((ntdll!_CM_PARTIAL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5bfc)->@"u".@"DevicePrivate" ((ntdll!_CM_PARTIAL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5bfc)->@"u".@"DevicePrivate" [Type: <unnamed-tag>] [+0x000] Data [Type: unsigned long [3]] kd> dx -r1 ((ntdll!unsigned long (*)[4])0xfffff8a0049d5c00) ((ntdll!unsigned long (*)[4])0xfffff8a0049d5c00) : 0xfffff8a0049d5c00 [Type: unsigned long (*)[4]] [0] : 0x1 [Type: unsigned long] [1] : 0x0 [Type: unsigned long] [2] : 0x0 [Type: unsigned long] [3] : 0xaaaaaaaa [Type: unsigned long] kd> dx -r1 ((ntdll!_CM_PARTIAL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5c24) ((ntdll!_CM_PARTIAL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5c24) : 0xfffff8a0049d5c24 : Private Device Resource [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR *] [<Raw View>] [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR] Type : 0x81 [Type: unsigned char] Flags : 0x0 kd> dx -r1 ((ntdll!_CM_PARTIAL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5c24)->@"u".@"DevicePrivate" ((ntdll!_CM_PARTIAL_RESOURCE_DESCRIPTOR *)0xfffff8a0049d5c24)->@"u".@"DevicePrivate" [Type: <unnamed-tag>] [+0x000] Data [Type: unsigned long [3]] kd> dx -r1 ((ntdll!unsigned long (*)[4])0xfffff8a0049d5c28) ((ntdll!unsigned long (*)[4])0xfffff8a0049d5c28) : 0xfffff8a0049d5c28 [Type: unsigned long (*)[4]] [0] : 0x1 [Type: unsigned long] [1] : 0x1 [Type: unsigned long] [2] : 0x0 [Type: unsigned long] [3] : 0xaaaaaaaa [Type: unsigned long] ``` When CM_PARTIAL_RESOURCE_DESCRIPTOR.Type is set to CmResourceTypeDevicePrivate (0x81), the following structure within the CM_PARTIAL_RESOURCE_DESCRIPTOR.u union is used: ``` struct { ULONG Data[3]; } DevicePrivate; ``` However, the size of the overall union is 16 (0x10) bytes on x64 builds, leaving the 4 bytes directly after DevicePrivate.Data unused. We have verified that regular (non-admin) users have read access to the affected registry values, and thus may successfully exploit the vulnerability. We have also confirmed the bug by enabling the Special Pools mechanism for ntoskrnl.exe, and seeing repeated patterns of marker bytes when inspecting the AllocConfig values in the default Windows Registry Editor (regedit.exe). A proof-of-concept program is not provided for this issue, but it has been observed at normal system runtime, and is quite evident in the code. 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.