CVE-2019-0808

admin 2022年4月23日02:24:10SecIN安全技术社区CVE-2019-0808已关闭评论7 views5155字阅读17分11秒阅读模式

一、 漏洞信息

CVE-2019-0808是发生在win32k中的一个空指针解引用漏洞,根据网上的blog介绍该漏洞在win32k!xxxMNMouseMove中产生。

二、 测试环境及漏洞复现

测试环境

POC:https://github.com/ze0r/cve-2019-0808-poc

靶机: win10 x86 SP1

漏洞复现

CVE-2019-0808

三、 漏洞成因分析

补丁分析

通过bindiff对xxxMNMouseMove函数进行对比,发现win32k!xxxMNFindWindowFromPoint函数新增对菜单窗口对象的校验。

CVE-2019-0808

对win32k!xxxMNFindWindowFromPoint进行详细分析时,可以看到xxxSendMessage成功获取到菜单窗口对象句柄后,通过HMValidateHandleNoSecure获取对应的菜单窗口对象,随后直接返回。

CVE-2019-0808

而在补丁文件中,HMValidateHandleNoSecure成功获取菜单窗口对象后会进行一系列的安全检查后(保证tagWndMenu、tagWnd、tagPopuMenu、tagMenu这四个对象均存在且不为NULL)才会返回。此时也猜测到这个漏洞产生的原因大概率是空指针解引用。

CVE-2019-0808

成因分析

在补丁分析中,我们猜测这是一个空指针解引用的洞,这里结合POC去印证。下图为执行POC后windbg抓到的cash现场,从堆栈中可以看到蓝屏触发点在win32!MNGetItem函数。

CVE-2019-0808

此时进行精准定位后,就是对ecx+0x20的poi操作发生错误。

CVE-2019-0808

进一步调试后,我们发现ecx的值居然也为空!!!

CVE-2019-0808

结合IDA对ecx的值进行溯源, 发现其存储的值是ptagMenu。

CVE-2019-0808

而ptagMenu的值是由菜单弹出对象tagPopuMenu+0x14提供的。

CVE-2019-0808

最终,我们溯源完成后知道ptagPopuMenu的值正是由通过xxxMNFindWindowFromPoint函数中HMValidateHandleNoSecure返回的菜单窗口对象tagMenuWnd+0xb0得到的。

CVE-2019-0808

至此,空指针解引用产生的原因已然明了。

四、 漏洞利用分析

漏洞利用分析部分是结合EXP,对其漏洞构造、提权利用进行详细阐述,方式为Q-A模式。

问题一,如何构造空的菜单对象(ptagPopupMenu->spmenu=NULL)

在漏洞成因过程中知道,tagMenu是由tagPopuMenu+0x14提供的,而tagPopuMenu是由tagMenuWnd+0xb0提供的。tagMenuWnd是在xxxMNFindWindowFromPoint在xxxSendMessage获取的弹出菜单句柄后通过HMValidateHandleNoSecure得到的。

CVE-2019-0808

从windbg的堆栈可以看到漏洞函数xxxMNUpdateDraggingInfo是由xxxMNMouseMove调用的,另外在window中win32k!xxxMNMouseMove是菜单窗口过程处理函数用来处理鼠标在菜单内移动的消息,如果此时鼠标由主弹出菜单移动到了子弹出菜单,那么在win32k!xxxMNFindWindowFromPoint内部就会通过xxxSendMessage对子弹出菜单发送消息来获取子弹出菜单的句柄,用来在后续代码中对子弹出菜单发送消息来完成绘制和鼠标选中等效果。

因此在EXP对应会创建两个弹出菜单并将其设置成为非模拟态(原因是模拟态会导致其他其他菜单发生阻塞,无法正常接收消息)

CVE-2019-0808

与此同时去创建一个伪造菜单窗口(tagfakeMenuwnd->spmenu==NULL),xxxSendMessage发送消息后替换其返回值(正常应该返回hMenuSub)。Ps:CSDN中也有定义lpClassName为#32768时,创建的是菜单窗口。

CVE-2019-0808

弹出菜单创建后,还需要一个窗口作为媒介来传递消息。

CVE-2019-0808

TrackPopupMenuEx的作用是在桌面上显示弹出菜单。

CVE-2019-0808

弹出菜单以及伪造窗口等都成功创建后,我们要想办法将xxxSendMessage的返回值替换为hWndFakeMenu,这里是通过SetWindowsHookEx和SetWinEventHook实现的。

CVE-2019-0808

下面就这两处hook的原因及作用进行详细介绍:

  1. SetWinEventHook

这里是对EVENT_SYSTEM_MENUPOPUPSTART事件进行了hook,原因是在TrackPopupMenuEx的内部实现xxxTrackPopupMenuEx中对菜单窗口(tagMenuWnd)、弹出菜单对象(tagPopupMenu)以及tagMENUSTATE创建并初始化后,会通过xxxWindowEvent向用户层发送EVENT_SYSTEM_MENUPOPUPSTART事件消息通知应用层的事件回调。

CVE-2019-0808

当弹出菜单成功显示后,向用户层发送EVENT_SYSTEM_MENUPOPUPSTART事件。

CVE-2019-0808

注册Event Hook后,首先在主弹出菜单(hMenuRoot)绘制完成后第一次进入此事件回调

CVE-2019-0808

并向其发送WM_LBUTTONDOWN消息即按下左键显示出子弹出菜单(hMenuSub)

CVE-2019-0808

子弹出菜单的显示是我们第二次进入事件回调并向hMenuSub发送WM_MOUSEMOVE消息从而形成一个从主弹出菜单到子弹出菜单的拖拽动作。

CVE-2019-0808

拖拽动作成功实现后,EXP就会顺利进行到xxxMNMouseMove函数中。

2.SetWindowsHookEx

用户层成功捕捉到由xxxMNFindWindowFromPoint中的xxxSendMessage发来的WM_MN_FINDMENUWINDOWFROMPOINT消息后通过SetWindowLongPtr将子弹出菜单窗口对应的过程函数(DefWindowProc)更改为SubMenuProc。

CVE-2019-0808

SubMenuProc最终返回用户态构造的窗口对象句柄hWndFakeMenu作为xxxMNFindWindowFromPoint函数调用xxxSendMessage的返回值,最终得到一个

ptagPopupMenu->spmenu=NULL的空指针。

CVE-2019-0808

CVE-2019-0808

到这为止,已经成功实现了xxxMNFindWindowFromPoint函数调用xxxSendMessage后返回的是伪造的窗口对象。但是,这并不代表着已经能够成功触发空指针解引用的操作。原因是第二次触发DisplayEventProc事件回调后,EXP向子弹出菜单窗口发送WM_MOUSEMOVE消息时就会在R0中调用一次xxxMNMouseMove。

CVE-2019-0808

此时,窗口句柄虽然可以被替换但在成功替换后,xxxMNMouseMove往下执行时并不会去调用xxxMNUpdateDraggingInfo。

CVE-2019-0808

通过IDA可以看到在xxxMNMouseMove中检查了tagMENUSTATE的fInDoDragDrop标志位是否置位,才会进入xxxMNUpdateDraggingInfo函数。

CVE-2019-0808

DisplayEventProc事件回调中虽然发送WM_MOUSEMOVE能够成功进入xxxMNFindWindowFromPoint的逻辑中,但是由于fInDoDragDrop没有被置位,因此并不能触发空指针解引用。

问题二,如何在xxxMNFindWindowFromPoint函数成功获取伪造窗口句柄成功后exp能够顺利进入xxxMNUpdateDraggingInfo的执行逻辑,触发空指针解引用的操作

对于这个问题,网上大神的blog给出了解决方案。我们可以通过手动调用NtUserMNDragOver函数来将fInDoDragDrop置位。

CVE-2019-0808

最后还需控制窗口句柄替换时机,设置一个全局变量bOnDraging在事件回调发送xxxMNMouseMove消息时xxxMNFindWindowFromPoint的xxxSendMessage返回正确的窗口句柄。

CVE-2019-0808

在我们手动调用NtUserMNDragOver后进入xxxMNFindWindowFromPoint的xxxSendMessage时替换子菜单窗口的窗口过程,因此我们的窗口过程回调需要稍作修改,并在手动调用NtUserMNDragOver前将全局变量bOnDrag置1:

CVE-2019-0808

至此,可以实现稳定的触发漏洞。

问题三,如何构造任意地址覆盖写漏洞

在漏洞成因分析中我们知道,产生崩溃的点是在xxxMNUpdateDraggingInfo-> MNGetpItem中,具体是spmenu的空指针解引用。而对于此类漏洞Win7中用户态可以通过ntdll!NtAllocateVirtualMemory函数分配零页内存利用。分配零页内存的原理比较简单,不再详述:

CVE-2019-0808

零页内存分配成功后,MNGetpItem函数中的对于菜单对象的取值操作并不会触发异常,我们可以看到此时pMenu的地址为0x0, pMenu->cItems [0x00000020] 也是可控数据。

CVE-2019-0808

接着在下方的if判断中uDraggingIndex < pMenu->cItems=0 不成立,导致返回pItem=0。我们需要控制程序流程走到红框分支,返回可控数据

CVE-2019-0808

因此需要在[00000020]设置一个合适的值(这里设置为0xffffffff)进入if分支。

CVE-2019-0808

返回值为uDraggingINdex*6C+[00000034]

CVE-2019-0808

uDraggingINdex的值可以通过wParam+0x10去获取

CVE-2019-0808

[00000034]是我们可控的数据,因此MNGetpItem的返回值也是可控的。接着往下发现在xxxMNUpdateDraggingInfo-> xxxMNSetGapState存在位修改操作

CVE-2019-0808

想必看到这里,我们知道此逻辑能够实现任意地地址的有限修改。具体如下:

addressToWrite = ret+0x4 = uDraggingINdex*6C+[00000034]+0x4

上述表达式addressToWrite代表着准备改写的任意地址,因此我们仅需设置[00000034]处的地址即可。

[00000034] = addressToWrite - uDraggingINdex*6C - 0x4

CVE-2019-0808

至此,我们就实现了指定地址值的有限修改功能。

问题四,如何实现本地提权利用(LPE)

通过分析exp知道,准备修改的地址是一个窗口对象tagWnd+0x90处的数据即cbwndExtra的值,cbwndExtra为此窗口扩展数据的大小,此处将其修改为0x4000000一个超长buf,目的是对其相邻的窗口进行越界写。

CVE-2019-0808

  1. 窗口对象喷射

首先申请100个窗口对象

CVE-2019-0808

通过pHmValidateHandle函数泄露窗口对象的地址并且以两个窗口的地址差小于0x3fd00为判断依据去寻找两个相邻的窗口对象。

CVE-2019-0808

CVE-2019-0808

成功找到后,将地址较高的窗口对象设置为primaryWindow,另外一个设置为secondaryWindow。

CVE-2019-0808

最后通过漏洞能力将primaryWindow的cbwndExtra修改为0x40000000。

CVE-2019-0808

2.越界写,执行shellcode

xxxMNMouseMove执行完xxxMNUpdateDraggingInfo并且成功将primaryWindow对象的cbwndExtra字段修改为0x4000000后,继续向下执行最后会向子菜单窗口发送0x1E5消息。

CVE-2019-0808

EXP成功拦截到发来的1E5消息后,开始计算primaryWindow对象末尾到secondaryWindow对象的strName.buffer的差值(offset)

CVE-2019-0808

CVE-2019-0808

SetWindowLongA将secondaryWindowAddress的strName.buffer的地址修改为secondaryWindow窗口对象的0x16的地址。

CVE-2019-0808

CVE-2019-0808

接着用SetWindowTextA将bServerSideWindowProc置为1,从而可以在内核执行我们的窗口过程函数。

CVE-2019-0808

CVE-2019-0808

修改0x16偏移的原因如下图所示:

CVE-2019-0808

最后向secondaryWindow窗口发送WM_ENTERIDLE消息执行shellcode(内核执行)。

CVE-2019-0808

```
secondaryWindow成功接收到WM_ENTERIDLE消息后首先会通过cs寄存器的值去判断当前执行上下文是否在内核态,之后开始执行shellcode,替换token。

```

CVE-2019-0808

```

Shellcode中除了必要的token替换,还清空了进程的Job对象指针,这是因为在Chrome的渲染进程中,即使shellcode替换了system进程的token,当前进程的token依然会继承自Job对象,并且Job不允许Chrome渲染进程产生新进程,因此需要先清空当前进程的Job对象指针。
```

CVE-2019-0808

至此漏洞利用过程分析结束。

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年4月23日02:24:10
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  CVE-2019-0808 http://cn-sec.com/archives/917277.html