关于MICROSOFT WINDOWS NFS V4 的漏洞频频出现，七月份，趋势科技研究团队就公布了一个CVE-2022-30136，该漏洞是在网络文件系统 （NFS） 的实现中发现的，并且是由于对 NFSv4 请求的处理不当造成的。未经身份验证的攻击者可以利用此漏洞在 SYSTEM 上下文中执行任意代码。

NFS v4是NFS v3的继承版本，主要针对WAN环境部署NFS做出改进并提出NFS分布式文件系统方案。NFSv4为虚拟分配提供的新特性。随着存储虚拟分配功能的普及使用，nfsv4可以为预留固定大小的存储空间;同样在文件系统上删除文件后，也能够在存储上面释放相应空间。

趋势科技研究团队在最新Windows 网络文件系统中发现一个远程执行代码漏洞。该漏洞是由于 NFS 请求中的字段验证不正确造成的。远程攻击者可以通过向目标服务器发送恶意 RPC 调用来利用此漏洞。成功利用会导致在 SYSTEM 上下文中执行任意代码。不成功的利用可能会导致目标系统崩溃。

Microsoft Windows 附带了几个旨在与非 Windows 文件共享进行通信和交互的网络功能。其中一个模块称为网络文件系统(NFS)。

网络文件系统（NFS）是文件系统之上的一个网络抽象，来允许远程客户端以与本地文件系统类似的方式，来通过网络进行访问。虽然 NFS 不是第一个此类系统，但是它已经发展并演变成 UNIX系统中最强大最广泛使用的网络文件系统。NFS 允许在多个用户之间共享公共文件系统，并提供数据集中的优势，来最小化所需的存储空间。

网络文件系统（NFS）从1984 年问世以来持续演变，并已成为分布式文件系统的基础。当前，NFS（通过 pNFS 扩展）通过网络对分布的文件提供可扩展的访问。

版本4由IETF开发，文档记录在RFC 3010(2000年12月发布)中，并在RFC 3530(2003年4月发布)和RFC 7530(2015年3月发布)中进行了修订。NFS允许用户像访问本地文件系统一样访问远程文件共享。共享可以设置不同的访问级别和权限，如读写、只读。此外，还可以使用IP/UID/GID/Kerberos安全性。NFS使用ONC (Open Network Computing)远程过程调用RPC (Remote Procedure Call)来交换控制消息。ONC RPC最初是由Sun Microsystems开发的，也可以称为Sun RPC。

当ONC RPC消息通过TCP传输时，它们的前面有一个指定消息长度的Fragment标头结构。这允许接收方区分通过单个 TCP 会话发送的多条消息。其他协议(如UDP)不使用该字段。注意，所有多字节值都是按照大端字节顺序编码的。

一般ONC RPC请求消息的结构如下：

Sun-RPC 消息中的 Credentials 结构如下所述：

上述结构中的 Flavor 字段用作 Contents 数据的类型标识符。由于历史原因，安全风格被称为身份验证风格。由于历史原因，安全方法被称为身份验证方法。RPC规范中定义了多种安全规则，如AUTH_NONE(0)、AUTH_SYS(1)、AUTH_SHORT(2)、AUTH_DH(3)和RPCSEC_GSS(6)。

RPCSEC_GSS 的 Contents 字段具有以下结构：

GSS Procedure字段定义了四种类型：RPCSEC_GSS_DATA(0)、RPCSEC_GSS_INIT(1)、RPCSEC_GSS_CONTINUE_INIT(2) 和 RPCSEC_GSS_DESTROY(3)。另外，对于GSS Service字段，有 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 Service字段设置为2 (rpc_gss_svc_integrity)，则Program-specific data字段的前缀结构如下：如果GSS Service字段设置为3 (rpc_gss_svc_privacy)，则对Program-specific data字段进行加密。

当Program字段设置为100003 (NFS)， 并且Procedure字段设置为1 (Compound)时，Program-specific data字段具有如下结构：

在请求数据中，对于消息中的每个操作：

操作码 OP_CREATE(6) 的操作数据；

操作码 OP_OPEN(18) 的操作数据；

操作码 OP_SETATTR(34) 的操作数据；

Data (fatattr4)的格式如下：

ACL 的属性数据（Bit12, 0x1000）；

NFS 的 Windows 实现中存在缓冲区溢出漏洞。该漏洞是由于在处理 Nfs4SrvAclBuildWindowsAclsFromNfsAcl 中的 ACL 属性数据时对 ACE_Count 字段的错误验证造成的。

只有在使用操作码6、18、34设置ACL属性数据时，该函数才容易受到攻击。

服务器分配一个大小为 (ACE_Count << 5) 的响应缓冲区。此大小在 Nfs4SrvAclBuildWindowsAclsFromNfsAcl 中存储为 uint64_t。这种大小的缓冲区是使用 NfsMemMgrBufferAllocate 创建的。然而，NfsMemMgrBufferAllocate只接受uint32_t的缓冲区大小，所以请求大小的上32位被忽略。

这允许攻击者指定一个 ACE_Count，这样(ACE_Count << 5) & 0xFFFFFFFF < ACE_Count。这将导致函数稍后在使用缓冲区时发生缓冲区溢出。

特别是，ACE_Count值高于0x8000000将触发此漏洞。

注意，ACE_Count = 0x8000000本身不容易受到攻击，因为当请求的长度为零时，NfsMemMgrBufferAllocate将出错。

攻击者可以利用此漏洞溢出堆缓冲区。成功利用可能会导致在 SYSTEM 上下文中执行任意代码。不成功的利用将导致目标系统崩溃。

检测设备需要检查RPC请求消息中的Program字段是否为100003（NFS），Procedure字段是否为1（COMPOUND），Program Version字段是否为4（NFS4）。如果找到，设备必须检查 ONC RPC 消息中的程序特定数据。

检测设备应在每次操作中检查易受攻击的操作码（6、18、34）。如果存在，设备应检查 ACL 属性数据的操作。如果存在 ACL 属性数据，则设备应检查 0x8000000 以上的 ACE_Count 字段。

消息中没有固定的偏移量可用于忽略非易受攻击的操作码，因为 NFS 操作不会始终包含操作数据的长度。必须处理完整的消息以确定是否有任何 ACL 属性数据。

如果 ACE_Count 字段大于 0x8000000，则应认为该流量是可疑的，可能有攻击者在利用此漏洞。

微软已在2022年8月修复此漏洞。在他们介绍的办法中，他们还列出了一种禁用NFSv4.1作为减少攻击的方法。然而，这可能会导致有关功能的丧失。

参考及来源：https://www.zerodayinitiative.com/blog/2022/8/31/cve-2022-34715-more-microsoft-windows-nfs-v4-remote-code-execution