Meltdown 和 Spectre 揭示超高速计算机的阴暗面

随着 CES 在拉斯维加斯全面展开,上周安全重磅炸弹的部分责任研究人员权衡了可能的后果

本周在拉斯维加斯举行的年度消费电子展 (CES) 上,数百家小工具制造商和软件公司将最新产品的成功押注于英特尔、AMD、ARM 和其他公司的最新最强大的处理器。但在上周的重磅炸弹之后,即使按照罪恶之城的标准来看,这些赌注也显得摇摇欲坠,因为许多处理器都受到被称为 Meltdown 和 Spectre 的严重安全漏洞的困扰。

处理器为几乎所有电子设备(包括展览中展示的数千辆汽车、家用电器和游戏系统)提供了一定程度的智能。现在已经很清楚,对更快处理器的贪得无厌的需求已经产生了阴暗面,因为芯片制造商在安全性方面偷工减料,使 可能数十亿 台个人电脑、移动设备和其他电子产品在未来几年内面临新一轮的数字攻击。

每台计算机都依赖于一种称为内核的软件,除其他事项外,该软件管理最终用户应用程序(电子表格、Web 浏览器等)与底层中央处理器和内存之间的交互。内核启动和停止其他程序,强制执行安全设置,并限制对设备内存和数据资源的访问。毫不奇怪,内核的速度决定了计算机的整体性能速度。芯片制造商通过将内核与其他在计算机上运行的程序隔离来保护内核,除非这些程序被授予特定权限(或“特权”)以访问内核。


支持科学新闻报道

如果您喜欢这篇文章,请考虑通过以下方式支持我们屡获殊荣的新闻报道 订阅。通过购买订阅,您正在帮助确保有关塑造我们今天世界的发现和想法的具有影响力的故事的未来。


Meltdown 瓦解了这种隔离,可能会让攻击者的恶意软件突破内核并窃取在那里找到的任何信息,包括个人数据和密码。Spectre 削弱了内核阻止恶意程序从使用处理器的其他软件窃取数据的能力。在 Google Project Zero、安全供应商 Cyberus Technology 和奥地利 格拉茨科技大学 独立工作的研究人员协调了上周对 Meltdown 的公告。Spectre 的存在在大约同一时间浮出水面,这归功于多所教育机构、网络安全研究公司和著名密码学家 保罗·科切尔 (pdf) 分别进行的调查。

科切尔最出名的是他帮助修订了一套用于保护计算机网络的密码协议,他与大众科学谈论了如何通过增加处理器速度的捷径导致了这两种漏洞,为什么花了数十年才发现这些漏洞,以及如何保护计算机免受攻击。

[以下是对话的编辑稿。]

芯片制造商是如何为了创造更快的处理器而损害计算机安全的?
根本问题是处理器时钟速度已基本达到极限。如果您想使处理器更快,则必须在每个时钟周期内完成更多工作。另一个变化不大的因素是内存速度。因此,优化成为设计计算机处理器时提高速度的关键。例如,如果您的处理器到达一个等待内存信息的位置,您不希望处理器在数据从内存返回之前处于空闲状态。相反,处理器可以推测它将接收到的信息,并开始提前工作而不是等待。当处理器猜测正确时,它可以保留这项额外的工作;处理器的推测执行带来了显着的性能提升。在正常情况下,由于处理器做出错误猜测并且必须回溯而损失的工作百分比是个位数。这种优化多年来一直是制造快速处理器的标准策略的一部分。

推测执行会产生哪些漏洞?
Meltdown 和 Spectre 都涉及这种捷径,但它们的工作方式不同,并且具有非常不同的含义。Meltdown 利用了一个问题,即普通的非特权代码可以读取具有内核权限的内存。这使得能够在其计算机上运行软件的攻击者读取物理内存的全部内容——例如,这在多个客户端共享同一服务器的云服务器中是一个大问题。

相比之下,Spectre 不涉及任何特权提升问题。相反,它利用了被攻击代码已经拥有的权限,但欺骗用户的系统推测性地执行程序永远不会合法执行的操作,并且这样做会泄漏内存内容。

是什么促使您最终发现 Spectre 的研究?
时间是这样的,我卖掉了我的公司(Cryptography Research),有时间亲自动手做研究。最初让我开始研究这个问题的是:我们在性能和安全性之间做了哪些权衡,以及在安全性不是首要任务的情况下增加了复杂性?在我报告这个问题并在我的[研究]论文中完全实施漏洞利用之后,我才完全意识到 Google Project Zero 在这方面的工作。时间是一个巧合,尽管实际上更令人惊讶的是,这些漏洞没有在很久以前就被发现。

Meltdown 由多个研究小组独立发现这一事实更有意义——部分原因是[安全研究员] Anders Fogh 在网上发布了一篇文章,他在文章中调查了这个问题,但没有发现问题。然后他发表了他的工作描述,这让其他人开始思考这个问题。还有一项名为 KAISERkernel address isolation to have side-channels efficiently removed 的缩写,内核地址隔离以有效消除侧信道)的补丁集的工作,旨在解决针对 KASLR (内核地址空间布局随机化—一种安全技术,通过将各种对象放置在随机而非固定地址来使漏洞利用更难) 的攻击。事实证明,这是 Meltdown 的修复程序,因此它也引起了人们对这个问题的关注。

为什么英特尔或其他芯片制造商没有首先发现这个问题?
这是一个合理的问题。他们现在正在处理的烂摊子比他们立即发现并修复问题所经历的痛苦要大得多。他们比外部研究人员更有优势找到这些漏洞,因为他们非常详细地了解所有技术的运作方式——而我是在没有任何内幕知识的情况下四处摸索。特别是对于 Spectre,还值得问一下,为什么 ARM 或更普遍地教授微处理器学术课程的计算机科学家没有发现它。一种可能的答案可能是,人们倾向于关注他们知道要关注的事情,而 Spectre 涉及一个跨越不同学科的问题,即从事技术某一方面工作的人对其他方面了解不多。

尽管如此,如果一些安全人员密切关注推测执行,并考虑它可能出错的不同方式,我认为他们中的很多人会意识到这是一个危险的想法。我怀疑在表面之下潜伏着更多令人不快的事情,我们没有看到,因为关于安全影响的问题没有被提出。

这对芯片设计的未来意味着什么?
我认为现在有点战争迷雾,很难提出明确的答案。芯片制造商可以做不同的、非常高级的事情。其中之一是将其留给软件开发人员来处理复杂的对策,但我认为这将在很大程度上失败,因为开发人员没有能力做到这一点。另一种方法是构建将具有不同安全属性的内核组合在一起的芯片,并在同一芯片上具有单独的执行单元,这些执行单元是更快还是更安全的执行单元。如果您在移动设备上玩游戏,则正在运行的是大型处理器内核。如果您的手机在休眠时收到数据包,则较小的内核会处理该数据包。

大多数真正关键的安全应用程序不需要大量性能。例如,如果您要进行电汇,则不需要大量[计算]能力来获得用户的确认以进行密码学并传输结果。如果您正在玩视频游戏,您真的不需要那种安全性,但它确实需要最佳性能。尽管如此,现在说 10 年甚至 5 年后情况会如何还为时过早。

这些漏洞的补丁如何降低处理器的性能?
Meltdown 的修复程序改变了内核内存的映射方式。在以前的工作方式中,普通用户代码和内核之间的切换是非常轻量级的转换。使用补丁后,必须在这些转换上完成更多工作。对性能的影响将取决于工作负载的类型。如果几乎所有程序的[数字运算]都在用户模式下完成,并且很少切换到内核模式,您将看不到任何显着的影响。相反,如果您有一段代码花费大量时间在用户模式和内核模式之间快速来回切换——例如从存储在非常快的磁盘上的文件中读取非常小的信息位——最终会增加大量开销。

Spectre 修复程序是如何工作的?
Spectre 目前只能缓解,而不能修复,因为该缺陷影响了许多不同的软件,包括操作系统、驱动程序、Web 服务器和数据库。其中一些软件(例如驱动程序)很少更新。许多软件也非常复杂,因此开发修复程序是一项艰巨的任务。对于某些 CPU,还有一些微代码补丁可以帮助缓解 Spectre 的一个方面,但是要使所有这些都正确工作,需要大量的工作。更糟糕的是,Spectre 涉及处理器中非常难以检测到的东西,这使得对策的测试非常非常困难。一些芯片将不得不更换,因为它们无法更新。因此,这是一个将长期存在的问题。

计算机用户如何保护自己?
在 Meltdown 方面,可以在操作系统级别实施许多修复程序——例如在 MacOS、Windows、Linux 和 iOS 操作系统更新中。如果您查看 Meltdown 的轨迹,肯定有攻击者可以并且将会攻击未打补丁的计算机,因此迫切需要应用该补丁。一旦安装了补丁,据我们所知,Meltdown 就不再是安全威胁。

另一方面,对于 Spectre,存在部分缓解措施。一些芯片无法更新,其他芯片可以更新,但制造带有芯片的产品的公司不会费心传递更新。通常,更新不会解决所有问题。尽管如此,重要的是要保持对风险的看法。我们每天都生活在许多其他安全威胁之中。Spectre 不一定比已经给安全专业人员带来巨大麻烦的其他漏洞更危险。使用 Spectre,您是在欺骗处理器在受害者计算机上运行的软件的特定位置做出错误的预测。攻击者需要了解受害者正在使用的软件代码,并为攻击工作设置正确的条件。因此,没有一个可以在许多计算机上运行的单一攻击程序。

从 Meltdown 和 Spectre 的发现中,最重要的启示是什么?
更大的图景与我们如何处理安全以及我们即使在最需要安全的地方也无法使系统安全有关。这些错误是该问题的一种症状。当您为与安全冲突的目标(例如速度)进行优化时,您可以合理地预期最终会遇到问题。Spectre 是安全/性能权衡的一个非常清晰的例子,其中速度优化直接导致了安全问题。这些安全漏洞影响所有主要的微处理器制造商这一事实确实表明,存在思想和注意力的失败,而不是个人甚至单个公司犯下的具体错误。

© . All rights reserved.