Login
CVE-2021-26432 NFS ONCRPC XDR 驱动协议远程代码执行漏洞验证过程
1，背景：
2021年8月份有两个较严重的漏洞需要关注，其中包括NFS ONCRPC XDR Driver 远程代码执行漏洞CVE-2021-26432以及RDP客户端远程代码执行漏洞CVE-2021-34535。
我们的目标是分析这些潜在影响可能较大的漏洞是否容易在实际的场景中被利用。这里，我们分析NFSXDR漏洞CVE-2021-26432。
2，NFSXDR驱动服务简介：
3，补丁分析：
分析补丁我们能比较容易确定漏洞修补的位置。
其中一处修改的地方是在函数OncRpcMsgpDecodeRpcCallVerifier中增加对参数的判断，
另一个则是在OncRpcBufMgrpAllocateDescriptorFromLLLargePoolAllocation函数中申请内存后，立即初始化该内存。
4，构造poc：
直观上来判断，RCE的cve更可能和第一个判断有关，这里我们通过追踪补丁的判断参数a1+296这个值的所有引用，最后在下面的函数中，找到了和它有关的另一个判断位置。
我们这里可以猜测这是一个计算消息头长度的函数，满足漏洞触发条件之一，需要这个长度固定为36。再查阅相关资料，我们能知道其余漏洞的触发条件是如果我们选择了RPC了验证方式为6（RPCSEC_GSS），则RPC中Credentials中的Flavor为1即AUTH_UNIX（而补丁修补后Credentials中的Flavor只能是为6）。然后我们根据协议文档尝试构造数据包，通过后续的分析对比可以明确上面的固定长度对应的是GSS_Token中的数据长度。
构造GSS_Token中的数据长度大于其在此情况下系统默认固定长度36即可触发漏洞路径。
由于对GSS_Token数据长度计算方式判断错误，返回的数据是可能会超过其默认申请的长度，我们可以通过灵活的构造请求包中的GSS_Token数据长度来控制这个漏洞可能会导致的效果：
如果其长度比默认的36长得不是太多（大致0x50左右），返回的数据包中会包含除GSS_Token数据之外其他的结构数据，这是一个可以导致一个信息泄露的效果：其泄露的数据具体来说包含整个对象内存的地址指针。如果我们的GSS_Token数据长度更长，则系统处理这些数据就会溢出掉后面其他所有结构数据直到其他未知内存（超出0x100基本会崩溃）。另外注意GSS_Token数据长度不是无限长度任意构造的，并且由于NFSxdr驱动中对数据接收的一些其他的限制，我们所能构造的溢出长度最长只能大概0x4000左右。
5，利用：
目前，我们已经有一个比较稳定的溢出。通常漏洞利用会尝试溢出一些特定的数据来得到一个指针执行机会。
我们考虑了以下两种方式：
A,通过溢出控制对象大小为0x900（*XdBD，这是一种NFSXDR为内部申请小于0x800的缓冲区对象）的内部链表缓冲区头，控制下一个缓冲区地址。构造写原语，一方面这种内部缓存的对象链表通常不需要校验其头部数据，这样溢出后会比较稳定。另一方面，通过控制这种内部链表结构，我们可以更加精确的控制其中的内存申请释放时机。
但一方面，这个单链表的长度太短了只有4。这种0x900的对象它的生命周期是随着RPC命令一起生成和释放的。一旦我们尝试风水布局，我们很难确定到这个4个对象的位置。另一方面我们不能通过前面提到的信息泄露的方式去知道这几个对象的地址。因为目前的信息泄露触发方式只能是在申请大缓冲区时才能满足漏洞条件的。而这个0x900的对象属于较小内存对象。
B,通过溢出控制OncRpcConnMgrpWskReceiveEvent中的OncRpcWiMgrpSrvWorkItemAlloc申请的内存（长度为0xa00的NLM对象），控制其对象中的引用指针。借助一个独立的信息泄露漏洞（参考本文最后一节），在我们布局的非分页内存中存放rop链来执行代码。
NFS本身是一个无状态的通讯协议，他使用了NLM对象来保证协议的中的资源正常访问读写。这里的NLM对象，有一些特性值得我们注意。
当多个RPC请求短时间传到服务端时，服务端会使用OncRpcConnMgrpWskReceiveEvent中这样的的一个流程去处理这些请求。
我打印了一部分我们关注的对象的生命周期。我们的目标是溢出NLM对象头部保存的OncRpcMsgProcessMessage函数指针。如下图：
该指针会在其释放前在NFS RPC工作线程中被调用：
该对象生命周期如下：
下图中的W-pool对应NLM对象。我们的目的是在NLM释放前调用其内部的OncRpcMsgProcessMessage指针时，覆盖该指针。
NFSXRD中，每一种不同的请求类型对应不同的的RPC请求，我们通过调整RPC请求中类型的位置和顺序能能够按照我们预期的时机触发溢出。，
NLM对象释放前，我们触发了溢出：
具体来说，我们申请一个0x1490的大内存对象（0x1490是我们可控制的申请读写数据的长度数据内存），之后使用NLM对象填充这些0x1490剩余的空洞。然后再释放所有0x1490的内存对象，在此时重新申请0x1490的读写请求包，在这其中一个包结构中触发漏洞。
以期望在所有的NLM对象释放前，溢出某一个NLM对象中的OncRpcMsgProcessMessage指针。
但结果并不能如预期那样，使漏洞刚好溢出到我们期望的目标上，即使是非常低的概率也没有。除此之外，我们还尝试了另一种不同的溢出思路：
第二种方法，大量发出某一种特定的PRC的指定请求（NLM请求），OncRpcConnMgrpWskReceiveEvent处理流程中会大量交替申请0xa00和0x900两种对象，并且这两个对象是成对出现的他们会各自占用0x1000的内存并形成一个较稳定的内存结构。当前面循环的RPC请求部分前面的相邻0xa00，0x900对象释放时，合并出0x2000的空闲内存。之后在还有剩余RPC请求存在的时候，构造漏洞溢出的内存长度为0x2000溢出其中的一个0xa00 NLM对象的头部。
6，总结：
但后续根据大量测试，我们并不能控制NLM对象能在我们漏洞触发时刚好释放。他有自己的时间计时器，其存在时间总也总是是低于我们的预期。并且另外一个关键的地方是，我们所构造的漏洞消息所申请的内存必须大于1K，太小则不能触发漏洞流程。这时我们也不能使用0x900或者0xa00这样本身存在的对象来占位。
我们最大的问题就是我们溢出的目标对象很难在我们控制得时机，布局成我们期望的位置（无论是0xa00 *RSWI还是0x900 *XdBD）。
综上，如果仅仅限制在最新的win10以上的NFSXDR协议内部，要实现利用似乎并不容易。但考虑到目前已知的在其他协议上的一些研究结果，如果是针对一些例如server2008这样较老系统上布置的NFSXDR服务。该漏洞是可能比较容易通过一些其他协议的内存布局方式而成功利用的。
7，新的漏洞：
在分析漏洞的补丁差异之初，我们有留意到补丁中对申请大于0x800的小内存时，才增加了一个初始化内存的操作，但当申请较小内存的时候，并没有对应的补丁代码。
如下：
按照思维惯性，我们在后续的分析中，就会带着这样的一个疑问进行后续的分析——当申请较小内存时，是否也会存在同原理的错误？
当我们在后续尝试exp的分析过程中发现，当我们构造数据包中GSSTOKEN数据长度如果不为4的整倍数时，返回的数据中最后几位字节有时会出现一些不确定的数据，（如下面的示例）
这是调整申请内存构造数据包大小时候偶然发现的（申请较小内存），深入分析后，最终的结果证明了我们之前的猜测。
该协议中对于数据包对齐的逻辑中，在复制数据时，对于非4的整数长度字节数据系统会仍然会自动填补其长度为4的倍数。而其返回的数据，就会有额外的不确定内存。其长度为4-x，x为GSSTOKEN除以4的余数。
然后，这样的一个错误能导致怎样的结果呢？
为了泄漏更长的数据，我们选择 x=1。 在下面的例子中，选择数据长度为 0x23d=0x23c+1；
我们可以通过增加4 的字节（或 4 的倍数）来设置读取请求数据的长度，以改变要泄露的其他感兴趣的不同位置的数据。 如下：0x241=0x23d+4。
什么这里的示例使用 0x23d 的读取长度？
这是因为当我们选择用较小的内存读取数据时，nfsxdr 默认申请内存的大小为 0x900。 在申请这个大小的内存时，很容易使用其他刚刚释放的大小相同的对象的内存。 在我们调试的环境win10中，Thread内核对象的大小也恰好是接近0x900。 如果是这样的话，这里选择读取 0x23d 长度的数据很可能对应到Thread 对象中存储的函数指针地址 0xfffff806 37efe930。 最后我们可以得到0xfffff8XX 37efe9XX这样的信息。 但是，长度为 8 字节的地址仍有 2 个字节无法确认。
通常来说，这样的信息泄露在现代windows系统上的作用似乎仍然受到地址随机化的限制，对于“37efe930“低位的“30”，一般来说有时我们是可能猜测的，但我们不能确认0xfffff806中的“06”。然而在一些过时的windows系统如win7，这样的信息泄露，足够取得一个内核指针信息。
所以在调用OncRpcBufMgrpAllocateDescriptorFromLLInlineBuffer时这里似乎可能仍然需要初始化其内存。
此错误已经在2月份修补为cve-2022-21993。
参考
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26432
