悬在云计算头上的达摩克利斯之剑 – 对于Meltdown 、Spectre事件的进展与思考

一步IT的历史简直就是一部“墙头变幻大王旗”的传奇小说。若论起来近40年来始终屹立不倒、笑傲江湖的企业，Intel 当属其中之一。在那本《硅谷百年史》书中，就不吝笔墨的描写了“仙童的叛徒“戈登.摩尔、罗伯特.诺伊斯以及安迪.格鲁夫创业的传奇故事。从1978年推出的8086处理器到今天握有x86处理器80%的市场份额，这一份骄傲何人能及？

电影《蜘蛛侠》里面有一句经典台词“With great power comes great responsibility“。但这一次，Intel 却因为自己的傲慢与失误让我们记住了这两个关于CPU的硬件漏洞Meltdown 、Spectre，也让我们不得不重新审视一下这个老而弥新的话题 – 云安全。

解释起来这一次事件的主角Meltdown 、Spectre是比较麻烦的一件事，涉及到许多现CPU 体系方面的复杂概念。众所周知CPU 的性能是推动整个IT行业发展的重要的动力。53年以来，半导体行业的“摩尔定律”更多的得益于工艺上的创举，并让我们不断的体验到高性能的CPU所带来的种种好处。但随着半导体集成度的不断提高，我们也非常担心摩尔定律是否已经趋近物理上的极限？为了保持CPU的发展势头，现代的CPU处理器创造性的采用了一些新的技术，其中预测执行（Speculative Execution）技术、多分支预测（multiple branch prediction）、 数据流分析（data flow analysis）三项技术，一起构成了乱序执行（out-of-order execution）的技术基石。

在80386时代，指令是顺序执行的。到了80486，引入了 流水线(Pipeline)技术，将一条指令执行的步骤以流水线的方式解放出来，一下子CPU的吞吐量就因此提高了将近3倍！虽然性能有所提高，但此时CPU还是严格按照指令的顺序串行执行的。但是人们还是不满足，试图解决流水线存在的空转和分支的问题。于是在奔腾II（Pentium Pro）面世的时候，Intel在CPU中引入了乱序执行技术。指令的执行方式从程序流驱动变成了数据流驱动，也就是只要部件的输入条件满足就可以开始执行了。流水线的吞吐量由此而大幅提高。与此同时，预测执行技术也被引入进来。分支预测会判断哪条分支最可能被执行，预测执行会直接取得那里的指令并立即执行。这样等分支结果出来后，实际上那里的指令早就开始执行了，流水线上总是满负荷运转，从而榨干了CPU的处理能力！

要注意的是，乱序执行和预测执行在遇到异常或发现分支预测错误的时候，CPU就会丢弃之前执行的结果，然后将 CPU的状态恢复到乱序执行或预测执行前的正确状态，并选择对应正确的指令继续执行。这种异常处理机制保证了程序能够始终正确的执行。但是问题来了，CPU在恢复状态的时候并不会恢复CPU缓存的内容，而我们今天介绍Meltdown 、Spectre这两组漏洞正是利用了这一设计上的重大缺陷，允许程序窃取当前在计算机上处​​理的数据。 关于上面的原理可以归纳为以下几点：

1、所有现代CPU在执行代码之前预先从系统内存中获取数据 。

2、预取数据放置在内部寄存器和CPU高速缓存中，读取速度比系统内存快得多。

3、自1993年以来，几乎所有的CPU都发布了预取数据，而且，大多数预取的数据都是预测的。

4、现在，Meltdown和Spectre漏洞背后的根本问题是：可能会诱使CPU将任意数据预取到内部寄存器和缓存中，这是CPU和操作系统本来可以防止的。

5、通过称为高速缓存定时侧通道攻击的先进技术，可以暴露预取数据。

6、攻击可以使用这些漏洞来逐步读取系统内存，而不在意任何保护机制。

通常情况下程序不允许从同一台计算上运行的其它程序中读取数据，但恶意程序可以利用Meltdown和Spectre来获取存储在其它正在运行的程序内存中的机密信息。 这可能包括存储在密码管理器或浏览器中的密码、个人照片、电子邮件，即时消息甚至关键业务文档。Meltdown和Spectre漏洞存在于在个人电脑、移动设备和云计算环境中的服务器上。 特别是云在云计算的环境中，这两个漏洞的存在可能导致用户数据被恶意程序所窃取。更进一步，在云计算上Spectre比Meltdown影响更大。Meltdown可使未经授权的应用程序读取特权内存，并获取运行在同一云服务器上进程的敏感数据，而Spectre可让恶意程序诱使虚拟机管理程序将数据传输到在其上运行的用户系统。问题说到这里是否感到一股寒意，而我们还可以继续无视这个问题的存在吗？

为什么会起了这么两个名字Meltdown和Spectre？

Meltdown 的含义是熔断，意指该漏洞融化了通常由硬件强制执行的安全边界。Spectre的含义是幽灵、妖怪，名字的来源是基于这个漏洞根本原因- 预测执行。由于漏洞很不容易修复，它将困扰我们很长一段时间。

·          Meltdown打破了用户应用程序与操作系统之间最基本的隔离。 这种攻击允许程序访问其它程序和操作系统的内存，并从而访问其内容。

·          如果计算机具有易受攻击的处理器并未安装必要的操作系统补丁，那么就有可能泄漏敏感的信息。无论是个人电脑以及云基础设施都会受此影响。

·          论文：https://arxiv.org/abs/1801.01207

·          Spectre打破了不同应用程序之间的隔离。 它允许攻击者欺骗其它程序泄漏他们的秘密，即使该程序遵循了最佳的安全实践。 事实上，所述最佳实践的安全检查实际上增加了攻击的面积，并可能使应用程序更容易受到Spectre的影响

·          Spectre比Meltdown更难利用，但它也更难以解决

·          论文：https://arxiv.org/abs/1801.01203

如何检测Meltdown和Spectre 漏洞的存在？

针对计算机的安全漏洞，我们通常会使用为其提供一个公共的名称，这个机制就是所谓的CVE （Common Vulnerabilities & Exposures，公共漏洞和暴露）。简单的说，CVE是由MITRE维护的信息安全漏洞名称标准。有了这个标准名称，我们就可以方便的在各种数据库中找到对应的信息。到目前为止，这两个漏洞被发现有三个已知的变体:

·        CVE-2017-5753 : 边界检查旁路，Spectre 漏洞

·        CVE -2017-5715 : 分支目标注入，Spectre 漏洞

·        CVE-2017-5754 : 无管理数据缓存负载，Meltdown 漏洞

由于这次危机的影响实在太大，自2018年1月2日The Register首次面向公众报道了这个事件之后不久，相应的针对这三个变体的检测工具陆续公布出来。

spectre-meltdown-checker （https://github.com/speed47/spectre-meltdown-checker）是一个开源的漏洞检测项目，通过运行它提供的一个脚本文件spectre-meltdown-checker.sh，就可以快速的检测当前系统针对这三个变体的状态。

使用步骤：

1、下载脚本
curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
或者
wget https://meltdown.ovh -O spectre-meltdown-checker.sh
2、修改脚本属性
chmod +x spectre-meltdown-checker.sh
3、执行脚本
sudo ./spectre-meltdown-checker.sh

输出结果：

注意：如果出现STATUS ：VULNERABLE 字样，则证明系统存在风险。

此外，IAIK/meltdown（https://github.com/IAIK/meltdown）也是一个很有意思的项目。不仅可以验证系统是否存在漏洞，还可以提供漏洞的很细节的演示。要注意是，项目的代码在运行前需要我们手工编译一下。

修补以及缓解的措施

事实上，从根本上修补着两个漏洞目前是无法实现的。只有寄希望下一代的Intel 采用全新的设计，甚至可能需要对微处理器体系结构进行重大改变才可能完全杜绝Spectre漏洞。

就目前而言，最有效的对策也只是针对具体的问题采用缓解的方案。而缓解方案的前提条件是：

1、操作系统和受影响的应用程序代码必须打补丁。

2、为了完全防止Spectre，CPU微码（microcode）或系统固件（firmware）需要更新。

3、操作系统的保护必须被激活。

4、在虚拟化环境中，为了防止所有已知的攻击，上述所有条件对于宿主机和被托管的虚拟机都必须是有效。

需要注意的一点，随着研究的深入或许还会有新的变体被发现，特别是Spectre漏洞。由于Spectre是一整类的攻击，所以一个补丁很可能无法完全解决。虽然这个漏洞的一些特殊案例已经在处理，Meltdown and Spectre

网站上也说：“Spectre不易修复，所以会长期困扰我们。”我们还需要持续的关注这个漏洞。

缓解措施对性能的影响

缓解措施对CPU性能的影响一直是这个事件中另一个值得讨论的话题。关于这个问题最标准的答案应该是性能的下降完全取决于其工作负载。对于这个问题，我们目前取得的共识包括了：

·        Spectre缓解的性能下降取决于正在使用的CPU系列：其分支预测器越先进，用于防御攻击的功能的影响就越大。

·        Retpoline技术（Google 提出的针对Spectre的缓解技术，它涉及在编译器编译时让间接分支跳转到不同的目标，减少易受攻击的乱序执行发生）在Skylake平台上不会产生缓解 ；但在Skylake上，其它的缓解技术对性能的影响较小。

·        在具有PCID（Intel 64架构下的进程上下文标识符）特性的平台上，Meltdown的影响会大大降低。

总体来看，Linux之父 Linus Torvalds认为性能的下降应该在5％左右 。而对于服务器工作负载，下表提供了一种参考。

Databricks 对这个问题，尤其是在AWS上运行的Apache Spark性能的影响也做了一些有益的测试。按照他们的测试AWS上的EC2 实例的性能的影响约在2%-5%（“While it’s difficult to be conclusive given the lack of controlled experiments, we have observed a small performance degradation (2 to 5%) from the hypervisor updates on AWS.”）。

AWS的公告以及资源

2018年1月2日关于Meltdown以及Spectre 被公布出来的第二天，AWS 就在其官网上发布了名为Processor Speculative Execution Research Disclosure (v1)的声明，告知了Amazon EC2将在接下来的几个小时内完成相应的保护，并提醒用户更新内核、升级补丁等。随着对问题研究的深入以及新的缓解措施的出现，这个声明在接下来的日子里被不断的更新，截止到目前已累计更新了18个版本之多。后续还可以通过这个网址持续关注相应的进展，https://aws.amazon.com/cn/security/security-bulletins/AWS-2018-013/。

此外，在Amazon Linux Security Center 网站上，也提供了对于CVE-2017-5753、CVE-2017-5715以及CVE-2017-5754 的变化跟踪。对于Amazon EC2的用户，则可以在在Processor Speculative Execution – Operating System Updates网站上得到关于AWS EC2支持的操作系统的补丁的情况，这些操作系统的版本包括了Amazon Linux & Amazon Linux 2、CentOS、Debian、Fedora、Microsoft Windows、Red Hat、SUSE、Ubuntu等。

AWS服务受影响情况以及建议采取的对策

截止到目前，AWS的服务受此事件影响的状况如下：

Amazon Linux存储库中提供了更新的Amazon Linux内核。 在2018年1月13日或之后使用默认Amazon Linux配置启动的EC2实例将自动包含更新的软件包，该软件包包含最新稳定的开源Linux安全性改进，以便在内核中满足CVE-2017-5715的要求，并基于之前合并的内核页表格隔离（KPTI），解决了CVE-2017-5754。 用户必须升级到最新的Amazon Linux内核或AMI，以有效地缓解CVE-2017-5715的流程到流程问题以及CVE-2017-5754在其实例中的流程到内核问题。

Amazon EC2

Amazon EC2机群的所有实例都受到了针对CVE-2017-5715、CVE-2017-5753和CVE-2017-5754的保护，没有实例可以读取另一个实例的内存，任何实例也不能读取AWS管理程序内存。对于绝大多数EC2工作负载，我们没有观察到有特别的性能影响。

截至2018年1月12日，完成了针对AWS平台的新英特尔CPU微代码部分，我们发现英特尔微代码更新导致少量崩溃和其他不可预知的行为。 这一变化缓解了这些少数情况下的这些问题。

到2018年1月12日，我们完成了对AWS平台的新Intel CPU微代码的取消激活部分，在那里我们看到了少量的崩溃和其他由Intel 微代码更新引起的不可预知的行为。这个影响仅涉及少数实例。

AWS Batch、Amazon EC2、Amazon Elastic Beanstalk、Amazon Elastic Container Service、Amazon Elastic MapReduce和Amazon Lightsail的用户建议修补其操作系统。

PV实例

经过对可用于此问题的操作系统补丁的持续研究和详细分析后，已确定操作系统保护不足以解决半虚拟化（PV）实例中的instance-to-instance concerns问题。 虽然PV实例受AWS管理程序的保护，但强烈建议用户迁移到HVM实例类型以获得更长期的安全优势。

Fargate、LAMBDA

提供托管服务的EC2 已完成修补，无需用户进行任何操作。

ECS优化的AMI

Amazon ECS Optimized AMI版本2017.09.g已经发布，该版本包含针对此问题的所有Amazon Linux保护。 建议所有Amazon ECS用户升级到AWS Marketplace中提供的最新版本。

更新Linux 内核

sudo yum更新内核。按照Linux内核的任何更新标准，在yum更新完成后，需要重新启动才能使更新生效。

Elastics Beanstalk

所有基于Linux的平台已被更新了，以包含针对此问题的所有Amazon Linux保护。建议Elastic Beanstalk用户将他们的环境更新到最新的可用平台版本。 使用托管更新的环境将在配置的维护时段内自动更新。

基于Windows的平台也已更新，以包含针对此问题的所有EC2 Windows保护。 建议用户将基于Windows的Elastic Beanstalk环境更新为最新的可用平台配置。

ElastiCache

ElastiCache管理的用户缓存节点都是专门为单个用户运行的缓存引擎，没有其他用户可访问的进程，也无法让用户在底层实例上运行代码。 随着AWS已经完成对ElastiCache底层的所有基础设施的保护，此问题不会给用户带来风险。

EMR

Amazon EMR将在用户的账户中运行Amazon Linux的Amazon EC2实例集群。 在Amazon EMR集群的实例中，关注进程隔离的用户应该按照上面的建议升级到最新的Amazon Linux内核。最新的Amazon Linux内核已经集成到新的小版本5.11.1、5.8.1、5.5.1和4.9.3中。用户可以通过这些发行版创建新的Amazon EMR集群。

RDS

RDS管理的用户数据库实例都是专门为单个用户运行数据库引擎，而没有其他用户可访问的进程，也无法让用户在底层实例上运行代码。 随着AWS已经完成对RDS基础的所有基础架构的保护，此问题不会给用户带来风险对。目前大多数数据库引擎RDS支持都报告没有已知的进程内问题。

于RDS for SQL Server数据库实例，已发布了包含以下引擎版本中Microsoft修补程序的操作系统和引擎修补程序：

SQL Server 2017（14.00.3015.40.v1）

SQL Server 2016（13.00.4466.4.v1）

SQL Server 2014（12.00.5571.0.v1）

SQL Server 2012（11.00.7462.6.v1）

SQL Server 2008 R2（10.50.6560.0.v1）

用户应该查看微软关于应用这些补丁并在选择时应用补丁的指导：

https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server。

对于RDS PostgreSQL和Aurora PostgreSQL，以缺省配置运行的数据库实例当前不需要用户操作。 一旦可用，将为plv8扩展的用户提供适当的补丁。 同时，启用了plv8扩展（默认情况下禁用）的用户应考虑禁用它们并在https://github.com/v8/v8/wiki/Untrusted-code-mitigations上查看V8的指导。

MariaDB，RDS for MySQL，Aurora MySQL和RDS for Oracle数据库实例的RDS当前不需要用户操作。

AWS上的VMware云

根据VMware的说法，“自VMSA-2018-0002中记录的补救措施自2017年12月初以来一直存在于AWS上的VMware Cloud中。”

有关更多详细信息，请参阅VMware安全与合规博客，并参阅https://status.vmware-services.io以获取更新状态。

Workspace

对于Windows Server 2008 R2的Windows 7用户的体验：

微软针对此问题发布了针对Windows Server 2008 R2的新安全更新。 这些更新的成功部署需要服务器上运行的兼容防病毒软件，如Microsoft安全更新中所述： https ://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-更新和防病毒软件 。 WorkSpaces用户需要采取措施才能获得这些更新。 请按照以下Microsoft提供的说明进行操作： https ://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution 。

对于Windows Server 2016的Windows 10用户的体验：

AWS已将安全更新应用于在Windows Server 2016上运行Windows 10的WorkSpaces。Windows 10内置了与这些安全更新兼容的Windows Defender AntiVirus软件。不需要进一步用户端的操作。

WorkSpaces Application Manager (WAM)

建议用户选择以下其中一种方案：

选项1：按照Microsoft提供的步骤，在运行WAM Packager和Validator的实例上手动应用Microsoft更新， 网址为：https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

。 此页面提供了更多说明和相关下载。

选项2：终止现有Packager和Validator实例。 使用标记为“Amazon WAM Admin Studio 1.5.1”和“Amazon WAM Admin Player 1.5.1”的更新AMI启动新实例。

反思

到目前为止，几乎所有的云平台的提供者都在认真的对待这一次的威胁。以AWS为例，在最短的时间内在其规模巨大的基础设施上针对Meltdown 和Spectre 的完成了修补。并且没有迹象表明存在可用的漏洞攻击可以针对这些云计算平台。从这个方面来说，云计算企业的技术能力以及运维水准在这一次事件得到了最好的证明。万幸，这一次并没有因为池鱼之殃而酿成云计算的灾难。但是从根本上解决类似Spectre这种存在20年之久的根深蒂固的漏洞，恐怕不是一件简单的事情。云计算上安全的挑战依然存在。经过10余年的发展，云计算平台几乎可以满足我们所有关于互联网的想法。很难想象互联网上的数据、信息以及服务并不依赖诸如AWS这样的平台。 从实质上说，云计算几乎就是今天的互联网。 虽然这些云计算企业拥有世界上最好的安全团队，但攻击面几乎是无限的并且是无法预测的。 处理来自诸如Specter这一类的威胁将是系统所面临的最严峻的安全问题之一 ,  这是一个不会很快消失的问题。此外，在 “责任共担模型”下，云计算的用户也必须要承担起自身的职责。这一次的事件中，如果缺少了云用户的参与与配合，恐怕焦头烂额的就应该我们每一位了。

最后，针对这次事件我看到的一个最为大胆的说法来自于ZDNET。他们文章的标题就是“为什么Intel x86必须死亡，我们认为以云为中心的未来取决于开源芯片”。有意思的说法，谁知道这会不会发生呢？