深入了解 Spectre 和 Meltdown

  • Chris Swan
  • 谢丽

2018 年 1 月 10 日

话题:安全DevOps语言 & 开发架构

看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!

本文是“Meltdown 和 Spectre 是什么及如何应对”的后续报道,将深入介绍:这两个漏洞的特点和潜在攻击,为什么在云服务提供商已经应用补丁的情况下还是要为云虚拟机打补丁,对性能及真实世界应用程序到底有什么影响,威胁建模的必要性,防病毒软件的作用,硬件如何受到影响以及长远看可能会带来什么变化。

SpectreMeltdown是典型的旁路攻击Zero 项目的博客上提供了详尽但复杂的说明。Raspberry Pi 创始人Eben Upton在博文中进行了简单明了的解释,说明为什么 Pi 不会受到影响,“我们在那种抽象环境里进行安全推断时会遇到抽象与现实之间存在轻微差别的情况,Meltdown 和 Spectre 就是这样的例子”。Graham Sutherland 在推特上说明了问题的本质:

副效应回滚有两个重要的例外:缓存和分支预测历史。这些通常都是无法回滚的,因为预测执行是一个性能特性,回滚缓存和 BHB 内容通常会损害性能。

这也就说明了为什么采用各种补丁处理这些问题会影响性能,因为它们的本质是确保缓存和分支预测历史在可能出现旁路攻击的地方可以回滚。Joe Fitz 将其比作图书馆里的图书,提供了一个完全非技术的解释。

Daniel Miessler 在文章“Meltdown 和 Spectre 差异简介”中提供了一个有用的图表:

在名称选择上,针对 Spectre 线索的补丁更细致多元。Meltdown 的处理相对简单(即使会有性能影响),而 Spectre 是可能会在某个时候困扰我们的一类问题(可能发现更多)。

GoogleAWSAzure都已经发表了声明,“我们的云(基本上)已经打好了补丁,现在轮到你们为虚拟机操作系统打补丁了”。遗憾的是,对于为什么要同时对虚拟机管理程序和虚拟机操作系统打补丁,他们没有提供多少细节。安全研究人员Katie Moussouris援引了 Robert O'Callahan博文中的一段话:“对于 CPU 供应商和云供应商而言,重要的是准确地说明他们采取了什么防范措施,什么攻击他们无法防范以及他们期望下游客户负责解决哪些问题”。AWS 在声明中明确表示,“我们会保障客户的实例不会受到来自其他实例的威胁”。这意味着,VM 操作系统仍然需要打补丁来防止 App 之间的攻击或者对特定 VM 内核的攻击,来自Amazon 的 Richard Harvey对此进行了确认。

当应用程序进行系统调用让 OS 内核帮它们做某事时,这些问题补丁的性能影响就会显现出来。为此,Loopback 测试可以呈现最坏的情况。Intel汇总了来自 Apple、Microsoft、Amazon 和 Google 的公告,他们普遍对这些补丁的影响轻描淡写。Cloudflare 的 CTO John Graham-Cumming表示,“我们会继续测试 #meltdown 和 #spectre 的各种补丁,但对 @Cloudflare 基础设施的影响似乎可以忽略”。同时,Aeron 创建者Martin Thompson指出,“在 Windows 上打好 Intel 的漏洞补丁后,Aeron 的良好表现让人意外。系统调用开销增加似乎会导致 Aeron 批处理增加,进而提高了吞吐量。”,虽然这种情况会影响延时。然而,有人报告了更为严重的性能影响。Syslog_NG 布道师 Peter Czanik发现,在 Fedora 上,编译时间从 4 分钟涨到了 21 分钟(虽然还不如在 OpenSUSE 上糟糕)。工程部门主管 Ian Chan表示,“在我们生产环境的部分 Kafka 代理 [d2.xlarge] 上,其底层的 AWS EC2 虚拟机管理程序(大概)已经应用了 #Meltdown 补丁。CPU 增长在 5% 到 25% 之间。”

来自微软的Jess Frazelle表达了对于威胁建模的一个重要观点,“在以为天要塌下来之前先考虑一下威胁建模。这些 Bug 需要访问机器。想一下,如果你运行着自己无法控制的代码……总而言之,那是你要关心的”。即使这些 Bug 没有直接提供权限提升(如果可以找到 root 密码,那可能就不严重)的方法,Spectre 或 Meltdown 也可能被以其他的方式利用,而大多数服务器系统已经受到了影响。终端用户设备风险更大,因为几乎无处不在的 Web 浏览器、广告中的 JavaScript 等提供了一个攻击路径,这就是为什么除了升级虚拟机管理程序和操作系统外还要升级浏览器。

防病毒(AV)软件也有自己的工作要做。目前,微软正在进行检查,确保 AV 供应商设置了注册表项,指明应用补丁是安全的,否则,AV 可能会试图访问与补丁冲突的内存,导致 Windows 崩溃。一段时间以后,主机入侵防护系统(HIPS)(与 AV 有大量重叠)可能就可以发现利用 Spectre 的尝试。

Intel 已经向 OEM 厂商提供了固件升级包,包括 CPU 微指令修复,不过显然,软件补丁的推出说明这些升级包本身并不够。那些升级包传播到终端用户还需要时间,而微软通过升级他们的 Surface 硬件做了早期示范。AMD 的公告对其 CPU 漏洞进行了低调处理,并指出这些升级包的性能影响几乎可以忽略。ARM提供了一个受影响的架构列表,其白皮书得到了广泛的补充,简明详尽,其中多半是与厂商无关的问题解释及补救措施。奇怪的是,用在 iPhone 和 iPad 中的基于 ARM 的Apple A 系列 CPU受到了 Meltdown 的影响,说明他们借用了 x86 处理预测执行的方法。ARM 还介绍了可以针对他们的部分核心设计发起的“Variant 3a” Meltdown 攻击,并提供了验证性攻击代码。白皮书中描述的可以缓解攻击的 CSDB barrier 操作已经在 ARM CPU 中提供,这说明已经可以防范可能出现的此类攻击,但是只有真正出现了攻击,才能知道这一措施的开销。

长远来看,有两个关键点。第一,Spectre 的风险可能还会存在一段时间——至少要等到现有的硬件被替换掉,对于嵌入式系统而言可能还要数十年。修复下一代 CPU 可能也为时已晚,至少会严重推迟他们的发布周期。这一系列的事件凸显出 CPU保护环其实只是另一种抽象——是油漆线,是吹哨子的裁判,而不是水泥墙。也许,解决这些问题的 CPU 不得不设计“硬墙(hard wall)”来达到防护目的。正如 Joe Fitz 所言,“我们可能需要从头再来了”。

查看英文原文A Deeper Dive into Spectre and Meltdown

安全DevOps语言 & 开发架构