谷歌微软合作一年找出新型Windows缺点

Google Project Zero (GPZ) 安全研究最显着的特点之一是其 90 天披露政策。一般来说，供应商有 90 天的时间来解决 GPZ 发现的问题，之后这些缺陷将被公开披露。但有时了解一个缺陷并为其开发修复程序需要超过 90 天的时间——有时甚至更长，例如当发现一类新的漏洞时。这就是去年在Spectre 和 Meltdown 处理器问题上发生的事情，并且在新的 Windows 问题上再次发生。

Google 研究员 James Forshaw 几年前在调查三年前发布的另一个 Windows 问题的可利用性时首先意识到可能存在问题。通过这样做，他发现了 Windows 在打开文件或其他受保护对象时执行权限检查的复杂方式。仔细查看相关部分表明，存在创建显着特权提升攻击的所有基本要素，使任何用户程序都可以打开系统上的任何文件，而不管用户是否应该具有这样做的权限。最大的问题是，这些元素是否可以以正确的方式组合以引起问题，还是运气好会使问题成为理论上的问题?

基本规则很简单：当从用户模式发出打开文件的请求时，系统应该检查运行尝试打开文件的应用程序的用户是否具有访问文件的权限。系统通过检查文件的访问控制列表 (ACL) 并将其与用户的用户 ID 和组成员身份进行比较来完成此操作。但是，如果请求是从内核模式发出的，则应跳过权限检查。那是因为内核通常需要自由且不受限制地访问每个文件。

除了这种安全检查，还有第二个区别：来自用户模式的调用需要严格的参数验证，以确保传递给函数的任何内存地址代表用户内存而不是内核内存。来自内核模式的调用不需要同样严格的验证，因为它们可以使用内核内存地址。

因此，用于在 NT 的 I/O 管理器组件中打开文件的内核 API 会查看调用者是从用户模式还是内核模式进行调用。然后 API 将此信息传递到系统的下一层：对象管理器，它检查文件名并确定它是否对应于本地文件系统、网络文件系统或其他地方。然后对象管理器回调 I/O 管理器，将文件打开请求定向到可以处理它的特定驱动程序。在整个过程中，请求的原始来源(内核或用户模式)的指示被保留和传递。如果调用来自用户态，每个组件都要进行严格的参数验证和完全访问检查;如果它来自内核模式，则应跳过这些。

不幸的是，这个基本规则不足以处理所有情况。出于各种原因，Windows 允许基本用户模式/内核模式拆分的例外情况。这两种异常都是允许的：内核代码可以强制驱动程序执行权限检查，即使尝试打开来自内核模式的文件，相反，内核代码可以告诉驱动程序跳过参数检查，即使尝试打开文件文件似乎源自用户模式。

这种行为是通过在各种内核函数和文件系统驱动程序之间传递的附加参数来控制的：有基本的用户或内核模式参数，以及一个强制权限检查的标志和另一个跳过参数验证的标志。

没有什么像看起来那么简单

作为另一个额外的微妙之处，I/O 管理器和对象管理器都可以指示底层组件执行权限检查，并且使用两个不同的标志来表示哪个组件负责强制检查。

Forshaw 发现，这些不同标志的交互方式存在微妙之处，从而产生了可能被错误处理的方式。当 I/O 管理器被告知跳过参数验证时，它通过不加选择地发出内核模式请求来做到这一点，即使该请求实际上来自用户模式。因此，跳过参数验证的请求也会禁用权限检查。这应该没问题，因为可以设置一个单独的标志来强制执行权限检查。但是错误的驱动程序可能会忘记这样做。

相反，当对象管理器强制进行权限检查时，它会不加选择地将请求标记为来自用户模式。这将启用参数验证和权限检查。

这进一步产生了一个潜在的问题场景：最初来自用户模式的文件请求可能将标志设置为跳过参数验证。驱动程序的作者知道他们仍然需要执行权限检查，所以他们也设置了 I/O 管理器的标志来强制进行权限检查。但是，它们不会设置(并且技术上不需要设置)对象管理器的标志来强制进行权限检查。

然后，I/O 管理器将把它转换为来自内核模式的请求，仍然设置了强制权限检查标志。然后，错误的驱动程序可能会检查请求以查看它是来自用户模式还是内核模式，而无需查看强制权限检查标志。该驱动程序看到请求来自内核模式，将跳过其参数验证和权限检查。这样做时，它允许用户模式程序访问文件，而无需验证用户是否被允许访问该文件。这是一个提权漏洞。

为了利用这一点，需要两个独立的部分。第一个是 Forshaw 所称的启动器：代表用户模式程序打开文件的内核组件，该程序设置标志以跳过参数验证并设置 I/O 管理器标志以强制进行权限检查，但不设置对象管理器标志强制进行权限检查。第二部分 Forshaw 调用接收器：一个驱动程序，用于测试调用是来自用户模式还是内核模式，但不检查单独的 I/O 管理器标志以强制进行权限检查。

Initiator 和 Receiver 这两个部分可以在不同的驱动程序中：关键是需要有某种方式将文件打开请求从易受攻击的启动器路由到易受攻击的接收器。Forshaw 可以找到启动器和接收器，但他找不到将它们链接在一起的方法。此时，他联系了微软，看看该公司是否能够找到任何易受攻击的配对。

通过访问 Windows 源代码，Microsoft 可以更轻松地找到启动器和接收器。该公司使用静态代码分析来检查危险模式，发现了 11 个潜在的发起者和 16 个潜在的接收者。微软还检查了 Windows 附带的第三方驱动程序，检查二进制文件并对任何可能有问题的例程进行逆向工程，以确保它们不可被利用。

经过所有这些工作，微软最终没有发现任何有问题的启动器和接收器配对。但是，该公司对这些潜在的启动器和接收器进行了一系列修复，它们将作为 Windows 10 版本 1903 版本的一部分提供。修复 Initiator 端意味着同时设置 I/O Manager和Object Manager 的标志以强制进行权限检查;修复接收器意味着检查内核/用户指示器和I/O 管理器强制检查标志。

Microsoft 强烈建议第三方驱动程序开发人员进行相同的更改，并且该公司考虑进行更改，以便在设置 I/O 管理器标志时，Windows 本身会自动设置对象管理器标志。但是，Microsoft 担心这可能会导致兼容性问题。

Windows 10 版本 1903 可能会在下个月发布，其中包含大部分修复程序。微软表示，一些修复程序已被搁置，等待额外的兼容性测试，或者因为它们位于默认禁用的已弃用组件中。随着 Microsoft 代码的基本固定，第三方驱动程序形成危险的发起方/接收方对的一部分的范围变得小得多。

标签：

版权声明：本文由用户上传，如有侵权请联系删除！