CVE-2020-0796 分析

CVE-2020-0796

3月13日凌晨左右，微软放了这个漏洞的补丁…所以稍微分析一下他的补丁

Bindiff

通过 bindiff 比较发现一个函数，且名字也蛮可疑的..

这个函数名叫 Srv2DecompressData 实际上和漏洞描述其实也差不多..

似乎是加了检查..我们打开IDA来比对一下两者的差别..

补丁

左边是有漏洞的版本，右边是 Patch 后的版本 .. 比对了一下发现似乎增加了一个检查..尤其是增加的一个叫

RtlULongAdd 的函数..

1	RtlULongAdd(ULONG ulAugend, ULONG ulAddend, ULONG *pulResult)

该函数的参数是两个似乎 recve 的数据以及一个变量..

NTSTATUS __stdcall RtlULongAdd(ULONG ulAugend, ULONG ulAddend, ULONG *pulResult)
{
  ULONG v3; 
  ULONG v4; 
  NTSTATUS result; 

  v3 = ulAugend + ulAddend;
  v4 = -1;
  if ( v3 >= ulAugend )
    v4 = v3;
  result = v3 < ulAugend ? 0xC0000095 : 0;
  *pulResult = v4;
  return result;
}

看了一下这个判断了 ulAugend + ulAddend 相加后的和是否小于其中一个加数..如果是则将其中一个赋值给返回值..从这里大概能初步判断是个什么漏洞了..基本能猜测是个整型溢出..

漏洞

我们来看一下未打补丁的版本…

看了一下..这里是将原本个值直接相加，并没有进行checkl… 然后分配内存..如果有问题 …应该是这里分配的内存太小..导致后续的缓冲区溢出吧？

由于我对这两个值不是很熟悉..所以这个时候开始查资料..

这个时候发现已经有人发文了…参考链接最后贴后面..

可以知道的是..这里的值一个是 OriginalCompressedSegmentSize 一个是 Offset/Length，他们描述如下:

OriginalCompressedSegmentSize (4 bytes) The size, in bytes, of the uncompressed data segment.

Offset/Length (4 bytes) If SMB2_COMPRESSION_FLAG_CHAINED is set in Flags field, this field MUST be interpreted as Length. The length, in bytes, of the compressed payload. Otherwise, this field MUST be interpreted as Offset. The offset, in bytes, from the end of this structure to the start of compressed data segment.

然后做了什么事情呢？

看代码，将分配的内存用 SmbCompressionDecompress 这个函数进行处理

我在 srvnet 里找到了 SmbCompressionDecompress 这个函数

然后又调用了 RtlDecompressBufferEx2 这个函数..最后调的是 RtlDecompressBufferXpressLz 这个函数…

这个函数在ntoskrnl. exe 里

这个函数做的是事情就是..

memcpy(ptr,src,len)

ptr 是由 SrvNetAllocateBuffer分配的UncompressBuffer，len 是从smb 包解析的解压数据的大小，这个值是攻击者可控的，由于前面没有检查..所以我们传入一个很大的值，使其触发整型溢出.分配一个较小的内存…此时 len又是一个大的值..所以导致了缓冲区溢出

参考链接

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/1d435f21-9a21-4f4c-828e-624a176cf2a0

http://blogs.360.cn/post/CVE-2020-0796.html