Twenty Year Anniversary

Microsoft Windows Kernel REG_RESOURCE_LIST Memory Disclosure

Microsoft Windows Kernel REG_RESOURCE_LIST Memory Disclosure
Posted Mar 21, 2018
Authored by Google Security Research, mjurczyk

The Microsoft Windows kernel suffers from a 64-bit pool memory disclosure vulnerability via REG_RESOURCE_LIST registry values (videoprt.sys descriptors).

tags | advisory, kernel, registry
systems | windows
advisories | CVE-2018-0899
MD5 | a3291f506262cdeab2f6590a2c2a2c56

Microsoft Windows Kernel REG_RESOURCE_LIST Memory Disclosure

Change Mirror Download
Windows Kernel 64-bit pool memory disclosure via REG_RESOURCE_LIST registry values (videoprt.sys descriptors) 

CVE-2018-0899


We have discovered a Windows kernel memory disclosure vulnerability through the body of "AllocConfig" registry values (of type REG_RESOURCE_LIST) corresponding to devices handled by videoprt.sys, which can be found under HKLM\SYSTEM\CurrentControlSet\Enum\*\*\*\Control\AllocConfig. The vulnerability affects 64-bit versions of Windows 7 to 10, and is very similar to <a href="/p/project-zero/issues/detail?id=1473" title="Windows Kernel 64-bit pool memory disclosure via REG_RESOURCE_LIST registry values (CmResourceTypeDevicePrivate entries)" class="closed_ref" rel="nofollow"> Issue #1473 </a>.

The leak was originally detected under the following stack trace (Windows 7):

--- cut ---
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
[...]
--- cut ---

and more specifically in the copying of the CM_RESOURCE_LIST structure:

--- cut ---
kd> db rdx rdx+r8-1
fffff8a0`049de874 01 00 00 00 01 00 00 00-00 00 00 00 00 00 00 00 ................
fffff8a0`049de884 05 00 00 00 01 03 01 00-b0 03 00 00 00 00 00 00 ................
fffff8a0`049de894 0c 00 00 00 aa aa aa aa-01 03 01 00 c0 03 00 00 ................
fffff8a0`049de8a4 00 00 00 00 20 00 00 00-aa aa aa aa 03 03 00 00 .... ...........
fffff8a0`049de8b4 00 00 0a 00 00 00 00 00-00 00 02 00 aa aa aa aa ................
fffff8a0`049de8c4 01 03 01 00 ce 01 00 00-00 00 00 00 02 00 00 00 ................
fffff8a0`049de8d4 aa aa aa aa 01 03 01 00-e8 02 00 00 00 00 00 00 ................
fffff8a0`049de8e4 08 00 00 00 aa aa aa aa ........
--- cut ---

In the above example, the 0xaa values are unitialized bytes originating from a pool allocation made in videoprt!pVideoPortReportResourceList.

If we dive deeper into the layout of the memory area, we can see that in all cases, the leaked bytes reside at the end of a nested CM_PARTIAL_RESOURCE_DESCRIPTOR structure:

--- cut ---
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])0xfffff8a0049de878)
((ntdll!_CM_FULL_RESOURCE_DESCRIPTOR (*)[1])0xfffff8a0049de878) : 0xfffff8a0049de878 [Type: _CM_FULL_RESOURCE_DESCRIPTOR (*)[1]]
[0] [Type: _CM_FULL_RESOURCE_DESCRIPTOR]

kd> dx -r1 ((ntdll!_CM_FULL_RESOURCE_DESCRIPTOR *)0xfffff8a0049de878)
((ntdll!_CM_FULL_RESOURCE_DESCRIPTOR *)0xfffff8a0049de878) : 0xfffff8a0049de878 [Type: _CM_FULL_RESOURCE_DESCRIPTOR *]
[<Raw View>] [Type: _CM_FULL_RESOURCE_DESCRIPTOR]
[0] : Port Resource: 0x3b0 of length 0xc [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR]
[1] : Port Resource: 0x3c0 of length 0x20 [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR]
[2] : Memory Resource: 0xa0000 of length 0x20000 [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR]
[3] : Port Resource: 0x1ce of length 0x2 [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR]
[4] : Port Resource: 0x2e8 of length 0x8 [Type: _CM_PARTIAL_RESOURCE_DESCRIPTOR]

kd> dx -r1 ((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*0))
((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*0)) : 0xfffff8a0049de88c [Type: unsigned long (*)[4]]
[0] : 0x3b0 [Type: unsigned long]
[1] : 0x0 [Type: unsigned long]
[2] : 0xc [Type: unsigned long]
[3] : 0xaaaaaaaa [Type: unsigned long]

kd> dx -r1 ((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*1))
((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*1)) : 0xfffff8a0049de8a0 [Type: unsigned long (*)[4]]
[0] : 0x3c0 [Type: unsigned long]
[1] : 0x0 [Type: unsigned long]
[2] : 0x20 [Type: unsigned long]
[3] : 0xaaaaaaaa [Type: unsigned long]

kd> dx -r1 ((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*2))
((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*2)) : 0xfffff8a0049de8b4 [Type: unsigned long (*)[4]]
[0] : 0xa0000 [Type: unsigned long]
[1] : 0x0 [Type: unsigned long]
[2] : 0x20000 [Type: unsigned long]
[3] : 0xaaaaaaaa [Type: unsigned long]

kd> dx -r1 ((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*3))
((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*3)) : 0xfffff8a0049de8c8 [Type: unsigned long (*)[4]]
[0] : 0x1ce [Type: unsigned long]
[1] : 0x0 [Type: unsigned long]
[2] : 0x2 [Type: unsigned long]
[3] : 0xaaaaaaaa [Type: unsigned long]

kd> dx -r1 ((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*4))
((ntdll!unsigned long (*)[4])(0xfffff8a0049de88c+sizeof(_CM_PARTIAL_RESOURCE_DESCRIPTOR)*4)) : 0xfffff8a0049de8dc [Type: unsigned long (*)[4]]
[0] : 0x2e8 [Type: unsigned long]
[1] : 0x0 [Type: unsigned long]
[2] : 0x8 [Type: unsigned long]
[3] : 0xaaaaaaaa [Type: unsigned long]
--- cut ---

There are two types of descriptors here: port and memory resources. Their corresponding structures within the CM_PARTIAL_RESOURCE_DESCRIPTOR.u union are:

--- cut ---
struct {
PHYSICAL_ADDRESS Start;
ULONG Length;
} Port;
--- cut ---
struct {
PHYSICAL_ADDRESS Start;
ULONG Length;
} Memory;
--- cut ---

The size of both these structures is 12 (0xc), but on x64 builds, the size of the overall union is 16 (0x10). This leaves the 4 bytes directly after the Port/Memory structures unused.

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.

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.



Found by: mjurczyk

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

Want To Donate?


Bitcoin: 18PFeCVLwpmaBuQqd5xAYZ8bZdvbyEWMmU

File Archive:

May 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    15 Files
  • 2
    May 2nd
    17 Files
  • 3
    May 3rd
    30 Files
  • 4
    May 4th
    29 Files
  • 5
    May 5th
    2 Files
  • 6
    May 6th
    3 Files
  • 7
    May 7th
    13 Files
  • 8
    May 8th
    27 Files
  • 9
    May 9th
    17 Files
  • 10
    May 10th
    15 Files
  • 11
    May 11th
    8 Files
  • 12
    May 12th
    2 Files
  • 13
    May 13th
    8 Files
  • 14
    May 14th
    7 Files
  • 15
    May 15th
    43 Files
  • 16
    May 16th
    19 Files
  • 17
    May 17th
    16 Files
  • 18
    May 18th
    15 Files
  • 19
    May 19th
    3 Files
  • 20
    May 20th
    7 Files
  • 21
    May 21st
    15 Files
  • 22
    May 22nd
    40 Files
  • 23
    May 23rd
    61 Files
  • 24
    May 24th
    0 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close