在趋势科技漏洞研究服务的漏洞报告摘录中，趋势科技研究团队的Guy Lederfein和Quintin Crist详细介绍了Microsoft Windows操作系统中最近修补的远程执行代码漏洞，该漏洞最初由Yuki Chen发现和报告。该错误是在网络文件系统 （NFS） 的实现中发现的，并且是由于对 NFSv4 请求的处理不当造成的。未经身份验证的攻击者可以利用此 bug 在 SYSTEM 上下文中执行任意代码。以下是他们关于CVE-2022-30136的部分文章，只是做了一些最小的修改。
Windows 网络文件系统中存在一个远程执行代码漏洞。该漏洞是由于对 NFSv4 请求的处理不当造成的。
远程攻击者可以通过向目标服务器发送恶意 RPC 调用来利用此漏洞。成功利用此漏洞可在 SYSTEM 上下文中执行任意代码。如果利用此漏洞不成功，可能会导致目标系统崩溃。
漏洞
Microsoft Windows 附带了几个网络功能，旨在与非 Windows 文件共享进行通信和交互。其中一个模块称为网络文件系统 （NFS）。
NFS是一种网络文件系统协议，最初由Sun Microsystems于1984年开发。版本 2 记录在 RFC 1094 中。版本 3 记录在 RFC 1813 中。版本 4 由 IETF 开发，记录在 RFC 3010（2000 年 12 月发布）中，并在 RFC 3530（2003 年 4 月发布）和 RFC 7530（2015 年 3 月发布）中进行了修订。NFS 允许用户以与访问本地文件系统相同的方式访问远程文件共享。可以在共享上设置不同的访问级别和权限，例如读写和只读。此外，还可以使用 IP/UID/GID/Kerberos 安全性。NFS 使用开放网络计算 （ONC） 远程过程调用 （RPC） 来交换控制消息。ONC RPC最初由Sun Microsystems开发，也可以称为Sun RPC。
当 ONC RPC 消息通过 TCP 传输时，它们前面附加了指定消息长度的片段标头结构（如下表所示）。这允许接收方区分通过单个 TCP 会话发送的多条消息。其他协议（如 UDP）不使用此字段。请注意，所有多字节值都按大端字节顺序进行编码。
Offset Size Description
0x0000 4 Fragment header, the highest bit is the last fragment flag,
lower bits represent the fragment size = N
0x0004 N RPC Message
一般而言，ONC RPC 请求消息的结构如下所示：
Offset Size Description
0x0000 4 XID
0x0004 4 Message Type
0x0008 4 RPC Version
0x000c 4 Program
0x0010 4 Program Version
0x0014 4 Procedure
0x0018 C Credentials
0x0018 C V Verifier
0x0018 C V N Program-specific data
Sun-RPC 消息中的凭据结构具有以下结构：
Offset Size Description
0x0000 4 Flavor
0x0004 4 Length, n
0x0008 n Contents
0x0008 n p fill bytes(padding to 4-byte alignment)
上述结构中的 Flavor 字段用作内容数据的类型标识符。由于历史原因，安全变种被称为身份验证变种。RPC 规范中定义了多种安全变种，例如 AUTH_NONE（0）、AUTH_SYS（1）、AUTH_SHORT（2）、AUTH_DH（3） 和 RPCSEC_GSS（6）。
变种RPCSEC_GSS的“内容”字段具有以下结构：
Offset Size Description
0x0000 4 GSS Version, 1 for this version
0x0004 4 GSS Procedure
0x0008 4 GSS Sequence Number
0x000c 4 GSS Service
0x0010 x GSS Context
0x0010 x p fill bytes(padding to 4-byte alignment)
有四种类型，如 RPCSEC_GSS_DATA（0）、RPCSEC_GSS_INIT（1）、RPCSEC_GSS_CONTINUE_INIT（2） 和 RPCSEC_GSS_DESTROY（3）， 在 GSS 过程 字段中定义。此外，在GSS服务字段中，有三种类型：rpc_gss_svc_none（1），rpc_gss_svc_integrity（2）和rpc_gss_svc_privacy（3）。使用 RPCSEC_GSS 对 RPC 客户端进行身份验证时，必须使用RPCSEC_GSS_INIT和RPCSEC_GSS_CONTINUE_INIT RPC 消息创建安全上下文。首先，RPC 客户端发送RPCSEC_GSS_INIT消息以开始创建上下文。然后，RPC 服务器决定是否需要另一个令牌进行创建。如果是这样，服务器将使用GSS_S_CONTINUE_NEEDED消息进行回复，并且客户端需要发送RPCSEC_GSS_CONTINUE_INIT消息才能继续。
如果“GSS 服务”字段设置为 2（rpc_gss_svc_integrity），则特定于程序的数据字段将以下列结构为前缀：
Offset Size Description
0x0000 4 Length
0x0004 4 GSS Seq Number
如果 GSS 服务字段设置为 3（rpc_gss_svc_privacy），则对特定于程序的数据字段进行加密。
当“程序”字段设置为“100003 （NFS）”并且“过程”字段设置为 1（复合）时，“程序”特定数据字段具有以下结构：
Offset Size Description
0x0000 4 Tag Length = T
0x0004 T Tag Data
0x0004 T 4 NFS Minor Version
0x0008 T 4 OP Count = O
0x000C T ... Request Data
NFS 的 Windows 实现中存在一个缓冲区溢出漏洞。该漏洞是由于响应消息大小的计算不正确造成的。服务器调用函数 Nfs4SvrXdrpGetEncodeOperationResultByteCount（） 来计算每个操作码响应的大小，但它不包括操作码本身的大小。这会导致响应缓冲区的大小因 OP 计数 * 4 个字节而太小。相应的缓冲区使用 OncRpcBufMgrpAllocate 分配。将响应数据写入缓冲区时，响应数据将溢出。由于该功能仅用于 NFS 版本 4，因此只有 NFS4 容易受到攻击。
OncRpcBufMgrpAllocate（） 实际上将使用 OncRpcBufMgrpAllocateDescriptorFromLLInlineBuffer（0x800） 或 OncRpcBufMgrpAllocateDescriptorFromLLLargePoolAllocation（） 分配数据，否则将使用 OncRpcBufMgrpAllocation（）
OncRpcBufMgrpAllocateDescriptorFromLLInlineBuffer（） 在描述符内的静态0x800字节中返回缓冲区。描述符结构具有0x50字节的空间，这些空间在静态缓冲区之后似乎未使用。
OncRpcBufMgrpAllocateDescriptorFromLLLargePoolAllocation（） 返回使用 ExAllocatePoolWithTag（） 分配的缓冲区。分配的字节数等于以下内容：
if (requested_size 0x48 < 0x1000)
allocate (requested_size 0x48)
else
allocate ((len 0x1ffff) >> 0xC) * 8 0x40
这意味着，对于任一缓冲区类型，必须溢出超过 0x48 个字节才能通过任一缓冲区类型中的填充。由于溢出的字节数为 OP Count * 4，因此必须在复合消息中至少执行 19 个操作，溢出才会产生任何影响。
攻击者可以利用此漏洞发送包含许多操作的精心编制的请求，从而导致大尺寸误判，从而导致缓冲区溢出。成功利用此漏洞可在 SYSTEM 上下文中执行任意代码。如果利用此漏洞不成功，可能会导致目标系统崩溃。
检测攻击
其中大部分信息在本文的前面部分都可以看到。为了您的方便，它被重新发布在这里。
当 ONC RPC 消息通过 TCP 传输时，它们前面附加了指定消息长度的片段标头结构（如下表所示）。这允许接收方区分通过单个 TCP 会话发送的多条消息。其他协议（如 UDP）不使用此字段。请注意，所有多字节值都按大端字节顺序进行编码。
Offset Size Description
0x0000 4 Fragment header, the highest bit is the last fragment flag
lower bits represent the fragment size = N
0x0004 N RPC Message
ONC RPC 请求消息的结构如上所示，Sun-RPC 消息中的凭据结构也是如此。如上所示，上述结构中的 Flavor 字段用作 Contents 数据的类型标识符。由于历史原因，安全变种被称为身份验证变种。RPC 规范中定义了多种安全变种，例如 AUTH_NONE（0）、AUTH_SYS（1）、AUTH_SHORT（2）、AUTH_DH（3） 和 RPCSEC_GSS（6）。
提醒一下，风味RPCSEC_GSS的“内容”字段具有以下结构：
Offset Size Description
0x0000 4 GSS Version, 1 for this version
0x0004 4 GSS Procedure
0x0008 4 GSS Sequence Number
0x000c 4 GSS Service
0x0010 x GSS Context
0x0010 x GSS Context
有四种类型，如 RPCSEC_GSS_DATA（0）、RPCSEC_GSS_INIT（1）、RPCSEC_GSS_CONTINUE_INIT（2） 和 RPCSEC_GSS_DESTROY（3）， 在 GSS 过程 字段中定义。此外，在GSS服务字段中，有三种类型：rpc_gss_svc_none（1），rpc_gss_svc_integrity（2）和rpc_gss_svc_privacy（3）。使用 RPCSEC_GSS 对 RPC 客户端进行身份验证时，必须使用RPCSEC_GSS_INIT和RPCSEC_GSS_CONTINUE_INIT RPC 消息创建安全上下文。首先，RPC 客户端发送RPCSEC_GSS_INIT消息以开始创建上下文。然后，RPC 服务器将决定是否需要另一个令牌进行创建。如果是这样，服务器将使用GSS_S_CONTINUE_NEEDED消息进行回复，并且客户端需要发送RPCSEC_GSS_CONTINUE_INIT消息才能继续。
如果“GSS 服务”字段设置为 2（rpc_gss_svc_integrity），则“程序特定的数据”字段将以下列结构为前缀：
Offset Size Descriptio
0x0000 4 Length
0x0004 4 GSS Seq Number
如果 GSS 服务字段设置为 3 （rpc_gss_svc_privacy），则特定于程序的数据字段已加密，必须解密后才能继续。
检测设备需要检查 RPC 请求消息中的“程序”字段是否具有值 100003 （NFS），“过程”字段是否具有值 1 （COMPOUND），以及“程序版本”字段是否具有值 4 （NFS4）。如果找到，设备必须检查 ONC RPC 消息中特定于程序的数据。
NFS复合的数据格式具有以下结构：
Offset Size Description
0x0000 4 Tag Length = T
0x0004 T Tag Data
0x0004 T 4 NFS Minor Version
0x0008 T 4 OP Count = O
0x000C T ... Request Data
仅当 NFS 回复中至少存在 19 个操作时，才会触发缓冲区溢出。由于 NFS 回复具有 NFS 请求中每个操作的响应，因此应监视大于 18 的 OP 计数字段的请求消息。
如果检测到具有大于 18 个操作的数据包，则应将该流量视为可疑流量;利用此漏洞的攻击可能正在进行中。
请注意，所有多字节值都以网络（大端）字节顺序表示。此外，如果正常流量包含类似的 NFS 复合请求，则此检测方法可能会生成误报。
结论
Microsoft 在 2022 年 6 月修补了此错误，并分配了 CVE-2022-30136。在他们的文章中，他们还列出了禁用NFSv4.1作为缓解攻击的方法。但是，这可能会导致功能丢失。此外，Microsoft 指出，除非安装了 CVE-2022-26937 的修补程序，否则不应应用此 bug 的更新。以适当的顺序应用这两个更新是完全解决这些漏洞的最佳方法。
,
