深入了解Spectre和Meltdown

安全 Google AWS Azure

摘要

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

正文

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

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

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

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

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

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

Google、AWS和Azure都已经发表了声明，“我们的云（基本上）已经打好了补丁，现在轮到你们为虚拟机操作系统打补丁了”。遗憾的是，对于为什么要同时对虚拟机管理程序和虚拟机操作系统打补丁，他们没有提供多少细节。安全研究人员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