Intel CPU 曝致命漏洞，Linux、Windows 面临重新设计，云计算厂商全受影响

导读：TPU 称，亚马逊、微软和谷歌是三个受影响最深的云计算厂商，如果漏洞被利用，那么在同一物理空间的虚拟用户 A 可以任意访问到另一个虚拟用户B的数据，包括受保护的密码、应用程序密匙等。

英特尔处理器芯片的一个基本设计缺陷已经迫使 Linux 和 Windows 内核进行重大重新设计，以解决芯片级安全漏洞。

内核开发者正在积极地检查开源 Linux 内核的虚拟内存系统，与此同时，微软预计在即将到来的周二补丁日，会公开发布 Windows 操作系统的必要变更：这些变化是在 11 月份和 12 月份发布的 Windows 内部版本的 beta 测试。

至关重要的是，对 Linux 和 Windows 的这些更新将会对英特尔产品造成冲击。结果仍然在基准测试中，估计使用英特尔处理器的系统性能将会出现 5%- 30% 的下降，具体取决于任务和处理器型号。最近的英特尔芯片具有 PCID 等功能，可以降低性能，你的计算成本可能也会改变。 

类似的操作系统，如苹果公司的 64 位 macOS，也将需要更新。这个缺陷是在 Intel x86-64架构硬件上，并且看起来更新微码无法解决它。必须在操作系统级别的软件中进行修复，或者购买新的没有设计错误的处理器。

英特尔芯片内部的漏洞细节处于封闭状态：对这些细节的禁令将在本月初解除，或许是微软下周二的补丁。实际上，Linux 内核的修补程序可供所有人查看，但源代码中的注释已被编辑以混淆该问题。

然而，这个缺陷的一些细节已经出现，这就是我们所知道的情况。

影响范围

据了解，该错误出现在过去十年中生产的现代英特尔处理器中。它允许普通的用户程序（从数据库应用程序到 Web 浏览器中的 JavaScript）在一定程度上辨别受保护的内核内存区域的布局或内容。

解决方法是使用所谓的内核页表隔离（KPTI）将内核的内存与用户进程完全分开。这次，Linux 内核团队仔细研究了强制取消内核中断（ Forcefully Unmap Complete Kernel With Interrupt Trampolines）（FUCKWIT），你可以感受下这多么令开发人员烦恼。

只要正在运行的程序需要执行任何有用的操作（如写入文件或打开网络连接），就必须暂时将处理器的控制权交给内核来执行。为了尽可能快速高效地从用户模式转换到内核模式并回到用户模式，内核存在于所有进程的虚拟内存地址空间中，尽管这些程序是不可见的。当需要内核时，程序进行系统调用，处理器切换到内核模式并进入内核。完成后，告知 CPU 切换回用户模式，并重新进入该过程。在用户模式下，内核的代码和数据保持不见，但出现在进程的页表中。

把内核想象成坐在云上的上帝，俯视地球。它在那里，没有正常的生物可以看到它，但他们可以祈祷。

这些 KPTI 补丁将内核移入一个完全独立的地址空间，所以它不仅对运行的进程是不可见的，甚至根本就不存在。实际上，这应该是不需要的，但显然英特尔芯片中存在一个缺陷，允许内核访问保护以某种方式被绕过。

这种分离的不利之处在于，在每个系统调用的每个系统调用和每个来自硬件的中断之间，在两个单独的地址空间之间切换是相对昂贵且时间明智的。这些上下文切换不会立即发生，而是强制处理器转储缓存数据并从内存中重新加载信息。这增加了内核的开销，并减慢了计算机的速度。

你的英特尔机器将因此运行速度较慢。

这个安全漏洞怎么会被滥用？

最好的情况下，恶意软件和黑客可以利用这个漏洞更容易地利用其他安全漏洞。

最糟糕的是，程序和登录用户可能会滥用这个漏洞来读取内核内存的内容。可以说，这不太好。内核的内存空间对用户进程和程序是隐藏的，因为它可能包含各种各样的秘密，比如密码，登录密钥，从磁盘缓存的文件等等。想象一下，在浏览器中运行的一段 JavaScript，或者在共享的公共云服务器上运行的恶意软件，能够嗅探受敏感内核保护的数据。

具体而言，就最好的情况而言，这个 bug 可能会被滥用来打败 KASLR：内核地址空间布局随机化。这是各种操作系统使用的防御机制，将内核组件放置在随机位置的虚拟内存中。这种机制可以阻止在内核中滥用其他漏洞的尝试：通常，利用代码（尤其是面向返回的编程漏洞）依赖于在存储器中的已知位置重用计算机指令。

如果你将内核的代码随机放置在内存中，攻击者就无法找到他们所需的内部组件来完全破坏系统。处理器漏洞可能会被利用来找出内核定位其数据和代码的内存位置，从而对软件随意篡改。

但是，英特尔芯片中的漏洞可能比上述的缓解旁路更糟糕。在圣诞节的一封 Linux 内核邮件列表的邮件中，AMD 表示，它不会受到影响。但是，这个信息的措辞让我们相当清楚地看到底层的诡计是什么：

AMD 处理器不受内核页表隔离功能所抵御的攻击类型的限制，AMD 微架构不允许内存引用（包括推测引用）在访问将导致页面错误时以较低特权模式访问较高特权的数据。

这里的关键词是“推测”。现代处理器，如英特尔，执行推测性执行。为了保持内部管道的指令符合要求，CPU 内核会尽力猜测接下来要运行的代码，取出并执行它。

从 AMD 软件工程师 Tom Lendacky 在上面提出的建议看来，Intel 的 CPU 可能在没有执行安全检查的情况下推测性地执行代码。似乎有可能以处理器开始执行通常被阻塞的指令（例如从用户模式读取内核存储器）开始执行软件，并且在特权级别检查发生之前完成该指令。

这将允许 ring-3 级用户代码读取 ring-0 级内核数据。

那很不好。这个漏洞的细节还没有得到证实，关于它的严重性的这个讨论已经足够了，但是可以这样认为：对 Linux 和 Windows 的更改声势浩大，而且正在快速推出。这表明它比 KASLR 旁路更严重。

此外，在 Linux 上分离内核和用户地址空间的更新是基于一组修补程序，这些修补程序是由奥地利格拉茨技术大学（Graz University of Technology）的 eggheads 创建的 KAISER 修补程序。他们发现（PDF） 可以通过在 CPU 的虚拟内存系统的旁路攻击中，从内核中提取内存布局信息来击败 KASLR。该团队提出了分离内核和用户空间以防止这种信息泄漏，他们的研究激发了这一轮的修补。

他们的工作由安德斯·福格（Anders Fogh）在 7 月份撰写了这篇有趣的博客文章所披露。那篇文章描述了他试图通过滥用推测执行从用户模式读取内核内存。虽然弗格无法提出任何有效的概念验证码，但他指出：

我的结果表明，推测执行确实继续，尽管违反了内核模式和用户模式之间的隔离。

看起来 KAISER 的工作与 Fogh 的研究有关，而且也正在开发一种通过滥用虚拟内存布局来打破 KASLR 的实际手段，这个团队可能会以某种方式证明 Fogh 是正确的 – 在 Intel x86 芯片上的推测性执行可以被利用来访问内核的内存。

共享系统（云服务）

该软件开发人员在周一发表的一篇重磅分享和推特文章中称，这个 bug 将会影响包括 Amazon EC2、Microsoft Azure 和 Google Compute Engine 在内的大牌云计算环境。

目前存在一个未公布的安全性错误，显然影响到所有实现虚拟内存的当代 [Intel] CPU体系结构，需要硬件更改才能完全解决。软件缓解的紧急开发正在公开进行，最近正在 Linux 内核中进行，类似的缓解在 11 月份开始出现在 NT 内核中。在最糟糕的情况下，软件修复会导致典型工作负载的巨大减速。

这种攻击会影响常见的虚拟化环境，包括 Amazon EC2 和 Google Compute Engine。

微软的 Azure 云（运行大量 Linux 和 Windows）将在 1 月 10 日进行维护和重启，大概会推出了上述修复程序。

亚马逊网络服务公司还通过电子邮件警告客户，预计本周五将有重大安全更新登陆，而不会涉及细节。

有传言说，一个严重的虚拟机管理程序错误 —— 可能在 Xen 中 —— 在 2017 年末进行。可能是这个传言的硬件缺陷：虚拟机管理程序可以通过这个内核内存的无序访问攻击，因此需要修补，强制重新启动来宾虚拟机。

英特尔的发言人尚未对此进行评论。

更新

这个 Intel 处理器的漏洞是真实的。一个 Vrije Universiteit Amsterdam 的系统与网络安全组的博士开发了一个概念验证程序，验证了这个从用户模式读取内核内存的芯片级漏洞。

经过查看该概念验证代码，少量的内核内存被泄露到了用户进程。

最后，据操作系统内核专家 Alex Ionescu 称，macOS 已经从 10.13.2 开始补上了该芯片设计漏洞。似乎 64 位的 ARM Linux 内核也有了一系列的 KAISER 补丁，完全分离了内核和用户空间，以防御 KASLR。