在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
感谢:Iceboy发现此问题并提供DUMP 漏洞描述:Win32k.sys是WINDOWS的GDI驱动程序,包含大量复杂的图形界面处理,由于其中大量代码是从WIN3.1中修改过来,因此成了WINDOWS漏洞多发之地。 这个漏洞主要是因为Windows 7 在其NtUserGetDc/NtUserGetDcEx函数中(也许不仅仅是这两个函数)不正确地使用了共享临界锁,导致了任何权限下的GDI程序可以引发内核BSOD,从而进行DOS攻击 漏洞分析: UserEnterUserCritSec的实现如下:
ExEnterPriorityRegionAndAcquireResourceShared是NTOSKRNL 导出一个提供给WIN32K使用的共享资源锁函数,这个函数将共享锁住gpresUser这个资源,同时返回当前线程的Win32Thread,即 KeGetCurrentThread->Win32Thread 同时内核函数ExEnterPriorityRegionAndAcquireResourceExclusive也与其类似。 而在windows 7 中,这两个函数进入前,改为了调用UserEnterSharedCrit,进入共享临界区 UserEntrySharedCirt的实现很简单
可以注意到,这里并不设置gptiCurrent,事实上,NtUserGetDc/NtUserGetDcEx会将这个函数保存在寄存器中以便使用CurrentWin32Thread中存放的数据 从关键临界转为共享临界,无疑这样的修改将提升NtUserGetDc/NtUserGetDcEx的效率,减少了锁竞争的可能,但是在这里这样修改是错误的. 因为在共享临界中,没有修改gptiCurrent,那么就很可能遇到gptiCurrent非法的状态,比如遇到一个没有做PsConvertToGuiThread的线程导致了gptiCurrent为空. WIN32K中有大量内部例程(经常以zzz,xxx开头),他们都认为在调用自己之前,gptiCurrent是一个有效的状态。这其中就包括了xxxDestoryWindow 一个BSOD的例子是:NtUserGetDc->GetWindowDc->GetDcEx->SpbCheckDce->SpbCheckRect->SpbCheckRect2->FreeSpb 调用到FreeSpb时,这里要释放一个spb对象了 接着就到 解决方案: 微软可能的更新手段: |
请发表评论