Windows Kernel double fetches in win32kfull!xxxImeWindowPosChanged and win32kfull!InternalRebuildHwndListForIMEClass
CVE-2018-0809(双重提取的意思是指用户层传入的r3指针与MmUserProAddress进行了校验，但是接下来又从r3接受相同指针，
这个间隙可以更改r3指针，让bsod,下面ecx就是r3指针 第一次取完 又取了一次)
We have noticed the following code in the win32kfull!xxxImeWindowPosChanged function on Windows 10 version 1709 32-bit (listing from the IDA Pro disassembler):
.text:000485A4 ; __try { // __except at loc_F3502
.text:000485A4 mov [ebp+ms_exc.registration.TryLevel], 0
.text:000485AB mov eax, [ecx]
.text:000485AD mov edx, ds:__imp__MmUserProbeAddress
.text:000485B3 cmp eax, [edx]
.text:000485B5 jnb short loc_485B9
.text:000485B7 mov edx, ecx
.text:000485B9
.text:000485B9 loc_485B9:
.text:000485B9 mov eax, [ecx]
.text:000485BB mov eax, [eax+8]
.text:000485BE mov [ebp+var_24], eax
.text:000485C1 mov [ebp+var_3C], eax
.text:000485C1 ; } // starts at 485A4
在代码片段的开头，ECX设置为用户模式地址。 这意味着在0x485BB处访问的地址从ring-3获取两次：首先在0x485AB处进行比较（与MmUserProbeAddress比较），然后在0x485B9处实际引用它。 这是一种称为TOCTTOU（使用时间检查时间）的竞争条件问题，并且可以允许恶意程序在两次读取之间更改已验证的地址以绕过安全检查。
让我们观察（在WinDbg中）如何利用这个bug。 首先，让我们在第一个设置断点win32kfull!xxxImeWindowPosChanged+0x15b:
3: kd> ba e 1 win32kfull!xxxImeWindowPosChanged+15b
在正常系统运行时很快就会遇到断点。 我们可以看到ECX指向可写的用户模式内存，并包含要清理和访问的指针：
3: kd> g
Breakpoint 0 hit
win32kfull!xxxImeWindowPosChanged+0x15b:
a4c386db 8b01 mov eax,dword ptr [ecx]
1: kd> dd ecx
028e4f10 028bb020 00000000 98e09ad1 8c000104
让我们继续下一条指令，将[ECX]的地址加载到EAX中：
1: kd> p
win32kfull!xxxImeWindowPosChanged+0x15d:
a4c386dd 8b15cc7ee6a4 mov edx,dword ptr [win32kfull!MmUserProbeAddress (a4e67ecc)]
现在，我们可以通过并发用户模式线程手动模拟[ECX]下的地址修改。 我们将其设置为无效的0xbbbbbbbb值
kd> ed ecx bbbbbbbb
通过单步执行接下来的几条指令，我们可以看到指针正确地通过了：
1: kd> p
win32kfull!xxxImeWindowPosChanged+0x163:
a4c386e3 3b02 cmp eax,dword ptr [edx]
1: kd> p
win32kfull!xxxImeWindowPosChanged+0x165:
a4c386e5 7302 jae win32kfull!xxxImeWindowPosChanged+0x169 (a4c386e9)
1: kd> p
win32kfull!xxxImeWindowPosChanged+0x167:
a4c386e7 8bd1 mov edx,ecx
1: kd> p
win32kfull!xxxImeWindowPosChanged+0x169:
a4c386e9 8b02 mov eax,dword ptr [edx]
1: kd> p
win32kfull!xxxImeWindowPosChanged+0x16b:
a4c386eb 8b4008 mov eax,dword ptr [eax+8]
--- cut ---
清理完成后，将再次从用户模式0xa01486e9获取相关地址，现在包含未映射的0xbbbbbbbb
value:
0: kd> ? eax
Evaluate expression: -1145324613 = bbbbbbbb
当我们让执行继续时，由于尝试访问无效指针而生成内核错误检查：
WINDBG log：
(0xBBBBBBC3,0x00000000,0xA4C386EB,0x00000000)
Driver at fault:
*** win32kfull.sys - Address A4C386EB base at A4C00000, DateStamp 262da7cd
[...]
DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: bbbbbbc3, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: a4c386eb, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)
[...]
TRAP_FRAME: d26c79a4 -- (.trap 0xffffffffd26c79a4)
ErrCode = 00000000
eax=bbbbbbbb ebx=b20030d8 ecx=028e4f10 edx=028e4f10 esi=b0ba1038 edi=b20004d0
eip=a4c386eb esp=d26c7a18 ebp=d26c7a80 iopl=0 nv up ei ng nz na po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010283
win32kfull!xxxImeWindowPosChanged+0x16b:
a4c386eb 8b4008 mov eax,dword ptr [eax+8] ds:0023:bbbbbbc3=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 81e4b1d2 to 81db4d24
STACK_TEXT:
d26c735c 81e4b1d2 00000003 54f0de0b 00000065 nt!RtlpBreakWithStatusInstruction
d26c73b0 81e4ac15 8ba9a340 d26c77cc d26c7840 nt!KiBugCheckDebugBreak+0x1f
d26c77a0 81db383a 00000050 bbbbbbc3 00000000 nt!KeBugCheck2+0x78d
d26c77c4 81db3771 00000050 bbbbbbc3 00000000 nt!KiBugCheck2+0xc6
d26c77e4 81d2fee8 00000050 bbbbbbc3 00000000 nt!KeBugCheckEx+0x19
d26c7840 81d30efe d26c79a4 bbbbbbc3 d26c78a0 nt!MiSystemFault+0x13c8
d26c7908 81dc831c 00000000 bbbbbbc3 00000000 nt!MmAccessFault+0x83e
d26c7908 a4c386eb 00000000 bbbbbbc3 00000000 nt!KiTrap0E+0xec
d26c7a80 a4c37b5d 00000000 a53a8510 a5968008 win32kfull!xxxImeWindowPosChanged+0x16b
d26c7ab0 a4c36abd 00000000 a53a8510 b2006180 win32kfull!xxxSendChangedMsgs+0xef
d26c7b18 a4c364b6 00000097 b2006180 b2006100 win32kfull!xxxEndDeferWindowPosEx+0x349
d26c7b38 a4c36292 00000000 00000000 00000000 win32kfull!xxxSetWindowPosAndBand+0x15e
d26c7b7c a4c6356f 00000000 00000000 00000000 win32kfull!xxxSetWindowPos+0x46
d26c7bdc a4c633de 00010000 000100ce 042bf748 win32kfull!xxxShowWindowEx+0x16f
d26c7c04 81dc4d17 000100ce 00000000 042bf754 win32kfull!NtUserShowWindow+0x90
d26c7c04 76fc1670 000100ce 00000000 042bf754 nt!KiSystemServicePostCall
--- cut ---
The same vulnerable construct was also found in the win32kfull!InternalRebuildHwndListForIMEClass function (EAX points into user-mode at the beginning of the snippet):
--- cut ---
.text:000F43F4 test eax, eax
.text:000F43F6 jz loc_4B617
.text:000F43FC mov edx, [eax]
.text:000F43FE test edx, edx
.text:000F4400 jz loc_4B617
.text:000F4406 mov ecx, ds:__imp__MmUserProbeAddress
.text:000F440C cmp edx, [ecx]
.text:000F440E jnb short loc_F4412
.text:000F4410 mov ecx, eax
.text:000F4412
.text:000F4412 loc_F4412:
.text:000F4412 mov eax, [ecx]
.text:000F4414 test byte ptr [eax+18h], 10h
我们注意到这些错误很可能是在2017年10月引入的，因为这是包含受影响代码的win32kfull.sys的第一个版本。 没有为这些问题提供概念验证程序，但是它们已经在正常的系统运行时观察和确认，并且在代码中非常明显。
漏洞利用可能允许本地经过身份验证的攻击者击败某些漏洞利用缓解（内核ASLR）或读取存储在内核地址空间中的其他机密。
from https://packetstormsecurity.com/files/146517/Windows-Kernel-Double-Fetches.html
Found by: mjurczyk