VULHUB ™

We have discovered a Windows kernel memory disclosure vulnerability through the contents of "FilteredConfigVector" registry values (of type REG_RESOURCE_REQUIREMENTS_LIST), which can be found under HKLM\SYSTEM\CurrentControlSet\Enum\ACPI\*\*\Control\FilteredConfigVector. The vulnerability affects 64-bit versions of Windows 7 to 10. The leak was originally detected under the following stack trace (Windows 7): ``` # RetAddr 00 fffff800`0295c064 nt!memcpy+0x3 01 fffff800`02970c81 nt!CmpQueryKeyValueData+0x3ae 02 fffff800`02971237 nt!CmEnumerateValueKey+0x211 03 fffff800`0268d093 nt!NtEnumerateValueKey+0x256 04 00000000`772abe6a nt!KiSystemServiceCopyEnd+0x13 ``` and more specifically in the copying of the CM_RESOURCE_LIST structure: ``` kd> db rdx rdx+r8-1 fffff8a0`049d5314 a8 00 00 00 0f 00 00 00-00 00 00 00 00 00 00 00 ................ fffff8a0`049d5324 aa aa aa aa aa aa aa aa-aa aa aa aa 01 00 00 00 ................ fffff8a0`049d5334 01 00 01 00 04 00 00 00-01 80 03 00 00 00 00 00...

We have discovered a Windows kernel memory disclosure vulnerability through the contents of "FilteredConfigVector" registry values (of type REG_RESOURCE_REQUIREMENTS_LIST), which can be found under HKLM\SYSTEM\CurrentControlSet\Enum\ACPI\*\*\Control\FilteredConfigVector. The vulnerability affects 64-bit versions of Windows 7 to 10. The leak was originally detected under the following stack trace (Windows 7): ``` # RetAddr 00 fffff800`0295c064 nt!memcpy+0x3 01 fffff800`02970c81 nt!CmpQueryKeyValueData+0x3ae 02 fffff800`02971237 nt!CmEnumerateValueKey+0x211 03 fffff800`0268d093 nt!NtEnumerateValueKey+0x256 04 00000000`772abe6a nt!KiSystemServiceCopyEnd+0x13 ``` and more specifically in the copying of the CM_RESOURCE_LIST structure: ``` kd> db rdx rdx+r8-1 fffff8a0`049d5314 a8 00 00 00 0f 00 00 00-00 00 00 00 00 00 00 00 ................ fffff8a0`049d5324 aa aa aa aa aa aa aa aa-aa aa aa aa 01 00 00 00 ................ fffff8a0`049d5334 01 00 01 00 04 00 00 00-01 80 03 00 00 00 00 00 ................ fffff8a0`049d5344 01 00 00 00 aa aa aa aa-aa aa aa aa aa aa aa aa ................ fffff8a0`049d5354 aa aa aa aa aa aa aa aa-01 01 01 80 11 00 00 00 ................ fffff8a0`049d5364 01 00 00 00 01 00 00 00-60 00 00 00 00 00 00 00 ........`....... fffff8a0`049d5374 60 00 00 00 00 00 00 00-01 01 01 80 11 00 00 00 `............... fffff8a0`049d5384 01 00 00 00 01 00 00 00-64 00 00 00 00 00 00 00 ........d....... fffff8a0`049d5394 64 00 00 00 00 00 00 00-01 02 01 80 01 00 00 00 d............... fffff8a0`049d53a4 01 00 00 00 01 00 00 00-00 00 00 00 00 00 00 00 ................ fffff8a0`049d53b4 00 00 00 00 00 00 00 00 ........ ``` In the above example, the 0xaa values at offsets 0x10-0x1b and 0x34-0x47 are uninitialized bytes originating from a pool allocation made in nt!PnpFilterResourceRequirementsList. If we dive deeper into the layout of the memory area, we can see that the first block of 12 consecutive leaked bytes corresponds to the "Reserved" array inside the IO_RESOURCE_REQUIREMENTS_LIST structure: ``` typedef struct _IO_RESOURCE_REQUIREMENTS_LIST { ULONG ListSize; INTERFACE_TYPE InterfaceType; ULONG BusNumber; ULONG SlotNumber; ULONG Reserved[3]; ULONG AlternativeLists; IO_RESOURCE_LIST List[1]; } IO_RESOURCE_REQUIREMENTS_LIST, *PIO_RESOURCE_REQUIREMENTS_LIST; ``` This is illustrated below: ``` kd> dt _IO_RESOURCE_REQUIREMENTS_LIST fffff8a0`049d5314 ntdll!_IO_RESOURCE_REQUIREMENTS_LIST +0x000 ListSize : 0xa8 +0x004 InterfaceType : f ( PNPBus ) +0x008 BusNumber : 0 +0x00c SlotNumber : 0 +0x010 Reserved : [3] 0xaaaaaaaa +0x01c AlternativeLists : 1 +0x020 List : [1] _IO_RESOURCE_LIST kd> dx -r1 ((ntdll!unsigned long (*)[3])0xfffff8a0049d5324) ((ntdll!unsigned long (*)[3])0xfffff8a0049d5324) : 0xfffff8a0049d5324 [Type: unsigned long (*)[3]] [0] : 0xaaaaaaaa [Type: unsigned long] [1] : 0xaaaaaaaa [Type: unsigned long] [2] : 0xaaaaaaaa [Type: unsigned long] ``` The second block of 20 uninitialized bytes resides inside a IO_RESOURCE_DESCRIPTOR record of type CmResourceTypeConfigData (0x80). While the overall union inside IO_RESOURCE_DESCRIPTOR is 0x18 (24) bytes long, only the first 4 of them are used to store a 32-bit value 0x00000001. The remaining part remains unused and contains left-over data from previous allocations: ``` kd> dt _IO_RESOURCE_DESCRIPTOR 0xfffff8a0049d533c ntdll!_IO_RESOURCE_DESCRIPTOR +0x000 Option : 0x1 '' +0x001 Type : 0x80 '' +0x002 ShareDisposition : 0x3 '' +0x003 Spare1 : 0 '' +0x004 Flags : 0 +0x006 Spare2 : 0 +0x008 u : <unnamed-tag> kd> ?? sizeof(_IO_RESOURCE_DESCRIPTOR) unsigned int64 0x20 kd> db 0xfffff8a0049d533c 0xfffff8a0049d533c+20-1 fffff8a0`049d533c 01 80 03 00 00 00 00 00-01 00 00 00 aa aa aa aa ................ fffff8a0`049d534c aa aa aa aa aa aa aa aa-aa aa aa aa aa aa aa aa ................ ``` 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 FilteredConfigVector 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.