该漏洞是在win32k中的bGetRealizedBrush产生的，是一个内核空指针解引用的漏洞，利用该漏洞可以完成提权操作。由于有公开的POC，所以对这个漏洞的分析和利用就变得简单，POC代码如下：

操作系统：Win7 x86 sp1

编译器：Visual Studio 2017

调试器：IDA，WinDbg

编译运行POC，根据信息可以得知，崩溃发生在win32k!bGetRealizedBrush偏移0x38的地址。崩溃的原因是此时的eax为0，函数要对[eax + 0x24]这个地址中的数据进行验证的时候，会因为[0x24]不是个合法地址而产生崩溃。

根据偏移，可以在IDA中找到相应的代码，根据IDA的解析，可以知道，此时是因为EBRUSHOBJ偏移0x34中的数据为0导致了崩溃

产生崩溃的原因是因为此时0地址并不是合法的地址，因此，只需要在0地址中申请一块内存，让0地址合法就可以防止崩溃，让程序继续运行。同时，该函数中存在函数调用，通过更改相关数据可以执行ShellCode。

在bGetRealizedBrush函数中，一共有三个地方执行了函数调用。其中的两个位置内容如下，都是通过第三个参数进行函数调用。由于无法控制第三个参数，所以这两个位置并不可以被利用。

另一个位置是可以利用的，因为ebx在上面赋值为第二个参数，也就是EBRUSHOBJ结构体以后就没有发生改把。所以，此时的eax就是EBRUSHOBJ偏移0x34的数据，也就是0。所以，只要将0x748地址中的内容赋值为ShellCode的地址，就会在下面因为执行call edi而成功执行ShellCode完成提权。

要达到此处的函数调用，需要绕过如下的两处验证。此时的eax和esi都是0，所以这两处就是在验证[0x590]和[0x592]是否为0。

如果跳转到loc_BF8406F是无法达到函数调用的地方完成提权，所以这两个地方都不能是0。因此，在0地址申请内存以后，除了在0x748赋值ShellCode地址以外，还需要将0x590和0x592赋值为非0值。

在崩溃点下断点以后，运行exp。此时，因为0地址有效，所以此时不会发生崩溃，程序可以继续向下运行。

继续向下运行到第一处验证，此时si为0，而由于0x590被写入了1，所以dx不为0，不会发生跳转。

继续运行到第二处验证，此时同理，不会发生跳转。

继续运行，到将0x748地址中的内容赋值给edi，此时的edi就会是ShellCode的地址。

当运行到函数调用处，edi保存的依然是ShellCode的地址

继续执行，就会执行ShellCode的代码完成提权

最终，程序会成功提权，如下图所示：

https://whereisk0shl.top/ssctf_pwn450_windows_kernel_exploitation_writeup.html

https://xz.aliyun.com/t/6008?page=1

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课