标签：sed 写入 发包 http res github 内核 info 这一
3月30日名为danigargu的研究员在github上分享的该CVE-2020-0796漏洞本地提权相关的利用https://github.com/danigargu/CVE-2020-0796
如下所示，经过测试在1909的设备上可以实现提权，分析发现这个利用还是比较巧妙的，之前分析漏洞的时候遗漏了其中的一些细节。
可以看到整个发包过程其实和poc基本一致，压缩数据包的主要内容是0x1108*A+（ktoken+0x40）。
如下所示为对应的数据包，由于1108个A的字符进行了压缩所以在流量上是没有这么多A的，这里可以看到下图所示需要修改的token中_TOKEN_PRIVILEGES的地址，也就是说这一个数据包就能实现当前进程内核token _TOKEN_PRIVILEGES域的修改。
如下所示是整个漏洞利用的数据包，前0x10个字节是压缩头，偏移0x4的CompressedSegmentSize和0xc的offset两个变量相加决定之后解压缩buffer的大小，但是可以容易的知道这里是一个整数溢出，从而在之后拷贝解压缩数据的时候导致越界写，0x20开始的0x14个字节为对应的压缩数据，其中蓝色水印即为当前token的_TOKEN_PRIVILEGES的偏移，中间蓝色框的部分为system token _TOKEN_PRIVILEGES的值，即通过这个包可以实现将当前token _TOKEN_PRIVILEGES修改位system的_TOKEN_PRIVILEGES。
这里之所以能利用就和Srv2DecompressData的解压缩过程有一定关系了，当溢出分配了较小的解压缩buffer v7之后（这里v7是一个buffer对象，对应的buffer指针在buffer+0x18处），调用函数SmbCompressionDecompress对0x20偏移的压缩数据解压，并将其拷贝到buffer对象的buffer指针中，这里拷贝的时候是从指针偏移0x10的位置开始拷贝，即会预留开始的0x10个字节，之后调用memove，将上图中蓝色框中的0x10个字节填充到buffer的开始预留的0x10长度的内存中。
如下所示为对应的buffer对象，偏移0x18处为实际的buffer指针，这里可以看到buffer指针指向的位置实际是在buffer对象的低地址处，也就是说通过解压缩中拷贝溢出buffer，最终是可以修改对应的buffer对象的buffer指针的，又由于之后的memove会将压缩数据包0x10-0x20处的数据（蓝色框中攻击者可控的0x10字节内容）复制到buffer指针开始至buffer+0x10处，这就给了攻击者一次任意地址写任意数据的能力，通过这个能力直接修改当前进程内核token的_TOKEN_PRIVILEGES来实现提权。
可以看到拷贝的起始地址为buffer+0x10，目标为buffer+0x11，长度为1107， 1107个A拷贝之后，正好后面就是buffer指针。
而我们的压缩数据实际上还没有拷贝完毕，还差之后的ktoken+0x40
此时buffer指针在拷贝完之后正好被修改为当前进程 token _TOKEN_PRIVILEGES的地址
之后调用memove进行拷贝，目标地址为buffer指针指向的地址，源地址为压缩数据包中压缩头之后到压缩数据0x20之间0x10长度的内容。这段内容实际也是攻击者数据包构造时完全可控的system _TOKEN_PRIVILEGES的值，由于此时buffer指针指向的地址被修改为当前进程的_TOKEN_PRIVILEGES的地址，从而实现了向当前_TOKEN_PRIVILEGES写入指定system的_TOKEN_PRIVILEGES的操作
如下所示，最终写入f2ffffbc0000001f
如下所示为对应的system进程的_TOKEN_PRIVILEGES，可以看到其值固定为f2ffffbc 0000001f，这也就是我们需要将其修改为f2ffffbc 0000001f的原因。
最终修改当前进程的token _TOKEN_PRIVILEGES，实现提权。
这里也可以看到如果在处理解压缩数据的时候，先直接将头部之后到压缩数据之前的蓝框部分拷贝的解压缩buffer中，再拷贝解压缩数据，就不会出现这一个利用点了。
转载请注明出处
参考链接
https://github.com/danigargu/CVE-2020-0796
标签：sed 写入 发包 http res github 内核 info 这一
原文地址：https://www.cnblogs.com/goabout2/p/12609810.html
