云基础设施之硬件安全威胁 – 作者:腾讯安全平台部-安全小百科

本文内容为XDef 2021的议题《云基础设施之硬件安全威胁》，特将PPT转为文字，以飨读者。

1. 云服务发展趋势

“我国云服务市场总体保持高速增长，2019年市场规模预测数为1300亿元，实际达到1334亿元，增速为38.61%。2020、2022年预计分别达到1737亿元和2903亿元。信通院最新预测显示，2023年市场规模接近4000亿元。

公有云市场迎来突进式增长，规模将超越私有云，2020年将达到949亿元，2022年预计1731亿元。

私有云市场保持稳定增长，向传统行业纵深拓展，2020年将达到788亿元，2022年预计1172亿元。

混合云市场增长空间巨大，2018年，在我国使用了云服务的企业中，采用混合云的企业仅占比13.8%，远低于国际水平（60%），我国混合云的应用比例仍存在巨大增长空间。”

公有云市场迎来突进式增长，规模将超越私有云，2020年将达到949亿元，2022年预计1731亿元。

私有云市场保持稳定增长，向传统行业纵深拓展，2020年将达到788亿元，2022年预计1172亿元。

——图文引用自灯塔大数据2020年报告

2. 硬件安全威胁

在云服务蓬勃发展的大背景下，云基础设施安全的重要性日益突出，其中，云基础设硬件安全威胁又具有供应链复杂、影响面大、修复困难、研究门槛高等特点。

回顾一下具有代表性的硬件安全事件：CVE-2019-6260影响ASPEED ast2400、ast2500两款主流的BMC SoC，主机能够直接刷写BMC固件，做到持久化控制；CVE-2016-8106只需要向Intel网卡发送特定的网络数据包就能使网卡宕机造成业务中断，攻击门槛低，后果很严重。2018年1月爆出的Spectre和Meltdown安全漏洞，会导致信息泄漏，影响几乎所有计算设备，包括服务器、个人电脑和移动设备。

研究者和设计师们更多地关注软件和网络层面的安全问题，而忽视了来自底层硬件的安全威胁。但是一个大家普遍接受的事实是：系统的整体安全性往往由安全性最低的环节来决定，即便上层软件协议再安全，如果底层硬件平台中存在安全缺陷，整个系统仍然是存在安全风险的。

CPU是计算机最核心的部件、BMC拥有服务器的最高权限、网卡是服务器与外界交换数据最直接的桥梁，下面选取这三个点展开讲述硬件安全威胁。

3. CPU安全威胁

从2018年1月谷歌爆出Spectre和Meltdown漏洞以后，大量研究人员开始关注CPU漏洞领域，陆续爆出Intel芯片大量漏洞：LVI、SWAPGS、L1TF/Foreshadow、MSBDS、SRBDS、MLPDS、TAA、MFBDS、MDSUM、CACHEOUT、Fallout等等。此外，ARM也受Spectre和Meltdown影响，AMD受Spectre影响。

值得注意的是：

1、上述所有的漏洞危害类型都是信息泄漏。
2、不同漏洞有不同的应用场景：Meltdown泄露内核数据，允许用户态读取内核任意地址；Spectre泄露目标上下文的数据，需要目标进程中有特定的代码片段。
3、已经出现实际可用的在野攻击。

3.1 cache

如图，1级cache访问时间在3到10ns，内存的访问时间在30到90ns，通过测量数据的访问时间，通过时间差异可以知道数据是在内存或者是被缓存在了cache中。

1、cache结构：

cache首先被划分成若干个set
每一个set被划分成若干个cache line
每一个cache line为缓存数据的最小单位，通常为64个字节
以32K cache为例:
cache line 大小为64
每一个set设置为8个cache line，即所说的8-ways
那么32K / 64 / 8，得到set的数量为64
即8 way set associative cache with 64 sets

2、寻址：

给定一个地址，如何找到匹配的cache？
以64位地址，32K cache为例，结合上图：
Cache line为64，则b=6
set数量为64，则s=6
则t=52
优先根据s的值找到属于哪一个set
再根据t的值找到属于哪一个line
最后根据b找到line中的偏移，由此可以通过地址索引到cache里面的数据。

3.2 CPU微架构体系

这张图展示的是CPU内部如何执行指令。可以看见分成3个部分：前端，乱序执行引擎和内存管道。

3.2.1 前端

负责从内存管道中预期指令，将指令解码入队列，解码成微码，我们知道指令并不是CPU执行的最小单元，微码才是，一条指令可能会被解析成多条微码。

同时可以看到微码的来源有三个途径，分别是指令预取、微码补丁、分支预测单元。
将指令解码成微码以后，微码将被送入乱序执行引擎。

3.2.2 乱序执行引擎

乱序执行模块有很多的计算单元，加减乘除，浮点运算，内存存取操作等。

乱序执行模块将微码运算分成两个部分，一个是执行，一个是生效。执行是将微码放到运算单元里面做计算并将结果暂存。生效则将结果真实反映在外部寄存器或者内存中。生效完成以后微码的执行才算真正完成。

为了提高效率，现代CPU都是多流水线，执行是乱序的，不必按照严格的先后顺序，后到来的微码可能会先执行。

生效则是严格按照代码的先后顺序，对于执行的前置条件和权限等进行校验。对于已经执行的微码在生效阶段如果发现它的条件不满足，则会将执行的结果丢弃，反之则将结果生效到寄存器或者内存管道中。

3.2.3 内存管道

内存管道则负责cache的读写，以及跟前端和乱序执行引擎交互数据。
Line Fill Buffer 等微架构组件会参与到cache读写过程中。

3.3 Spectre

3.3.1 漏洞原理

前面讲了预测执行。当flag预测为真，中间这行代码将被预测执行。

在生效阶段发现flag其实为假，则将数组访问的结果丢弃，并未将结果反馈到内存或者寄存器中。但是将结果丢弃的时候，数据访问对cache的影响并没有随着消除。

3.3.2 漏洞利用步骤

1、数组arr定义为256个块，每个块大小是4K。
2、将数组arr从cache中清除。
3、设置Flag 为false。预测执行中间两行代码，生效阶段将结果丢弃。但是对cache的访问保留了下来。即arr[secret * 4096] 这个数据缓存在了cache中。
4、通过测量arr 256个块，访问时间较短的一个认为是在cache中。由此可以知道secret的值是多少。从而达到了信息泄露的目的。

3.3.3 预测错误

如何让CPU对于分支预测错误呢？

首先执行call 1f，通常情况当1f执行完以后返回到下一条指令movzbq (%rsi), %rax，所以CPU会预测执行这条指令。我们在1f函数中将栈上面的返回值调整至2f，实际执行时1f执行完以后会返回到2f，而不是movzbq指令，这样就实现了让CPU预测错误。从而让movzbq开始的几条指令预测执行。

3.3.4 漏洞利用条件及危害

条件：

预测执行。
泄露的地址要在1级cache里面缓存。
泄露的地址要在地址空间里面有映射。

** 危害：**

泄露进程上下文数据。

3.4 meltdown

3.4.1 漏洞原理

Meltdown跟Spectre的差异在于利用的不是预测执行，而是乱序执行。

rsi存放的是内核地址，那么movzbq (%rsi), %rax将会触发异常，被xbegin xend指令捕捉到，接着执行ret指令。

但是由于乱序执行，shlq $STRIDE_SHIFT, %rax 和 movzbq(%rdi,
%rax), %rax会优先执行，在生效阶段结果被丢弃，但是在cache留下的缓存没有被清掉。从而导致了信息泄露。

3.4.2 漏洞利用条件及危害

条件：

乱序执行。
泄露的地址要在1级cache里面缓存。
泄露的地址要在地址空间里面有映射。

危害：

普通用户权限可以读取内核数据。

3.4.3 Meltdown武器化工具

详情参考: https://security.tencent.com/index.php/blog/msg/184

3.4.4 Meltdown缓解措施

KPTI，内核页表隔离。

简单来说就是针对漏洞利用的必要条件：泄露的地址要在地址空间有映射。只需要让用户态的地址空间不再映射内核的地址就可以了。

具体来讲，采用两套页表。内核页表映射完整的地址空间，而用户态页表只映射用户态地址，内核地址不再映射。

弊端：
用户态内核态切换以及进程切换会导致页表冲洗，进一步导致cache冲洗，会带来性能上面的损失。

#3.5 MSBDS

为了加速，在预测执行，乱序执行的时候，取数据的操作紧跟在存数据的操作后面，只要低12位地址一样则认为是同一个地址，会将前面的数据返回。

victim + 0x30a 和 attack + 0x30a 被认为是同一地址，从而泄露出victim的值。

这个漏洞是怎么被发现的呢？

在专利《Resolving false dependencies of speculative load instructions》，有这样一段话，

研究人员在浩浩文海中发现了它，说在310号操作中选用部分物理地址而不是全部地址做校验。经过实验发现了此漏洞。

3.6 Line Fill Buffer

3.6.1 微架构

回顾这张图：

前面提到：Line Fill Buffer 等微架构组件会参与到cache读写过程中。Line Fill Buffer跟L2 Cache相关联。

在开启超线程的CPU核心上面，同一个核心上的两个超线程共享L2 Cache，前面我们知道Line Fill Buffer跟L2 Cache关联。

那么，同一个核心上的两个超线程共享同一个Line Fill Buffer。

3.6.2 漏洞原理

当执行load的时候，会同时查询L1D cache和Line Fill Buffer,并将数据存入Line Fill Buffer.当完成这些操作以后释放掉Line Fill Buffer。

如果在L1D cache中没有查询到，那么会分配一个Line Fill Buffer，加速cache的运作。

释放掉Line Fill Buffer 以后里面的值并不会被清0，当下一次分配到的时候，前面的值就会被预测执行读到。

3.6.3 漏洞利用步骤

Victim:

受害者进程通过mm_mfence指令让内存操作使用Line Fill Buffer。

Attack:

位于同一个核心的另外一个超线程作为攻击者，通过预测执行，乱序执行访问一个任意地址，即使地址没有映射例如地址0，也可以通过Line Fill Buffer泄露数据。

3.7 CPU漏洞研究方法

难点：微架构组件算法没有文档；没有办法进行调试，逆向，度量。

研究方法：阅读官方文档，专利；漏洞paper；Fuzz框架；性能计数器。

3.7.1 CPU漏洞fuzz框架

1、将已有漏洞存在的攻击手法，揉碎打乱，对内存页表属性，cache属性，异常，地址对齐等等元素组合起来成代码片段，来对CPU做fuzz。

2、将能够实现信息泄露的代码片段挑选出来。

3、结合性能计数器和人工分析来判断是否有新的漏洞发现。

3.7.2 性能计数器

PMC (Performance Monitor Counter)

为了解在执行应用程序时在处理器中发生的情况，处理器架构师设计了一组特殊的寄存器，它们对在处理器执行指令时发生的事件进行计数。

上图简单列举了几个性能计数器。

3.7.2.1 研究方法

1、性能计数器对漏洞POC，fuzz框架跑出泄露的样本进行测量发现：使用Line Fill Buffer了的场景都可以进行泄露，性能计数器L2_LINES_IN.ALL: xxx 有值预示着使用了LFB

2、在以下情况下会使用到Line Fill Buffer，性能计数器 L2_LINES_IN.ALL里面有值

•    无效地址：因为地址无效，所以在cache中找不到相应cache line，使用LFB加速( MFBDS )

•    地址缓存属性为MEM_UC：因为不使用cache，使用LFB加速（MDSUM）

•    L1 cache miss：L1 cache miss，从L2， L3，memory加载数据，使用LFB加速（cacheout）

•    writeback类型cache，数据从L1 cache写入memory的时候：使用LFB加速（cacheout write）

3、综上，当L1 cache单独不能满足读写需求的时候，就需要用到LFB来加速，就会有泄露的风险，因此可以用L2_LINES_IN.ALL计数器来判断哪些指令会触发LFB使用。

3.7.2.2 SRBDS

NanoBench（https://github.com/andreas-abel/nanoBench.git ）提供了一个框架可以对指令执行的性能计数器进行统计，针对指令执行的结果去寻找L2_LINES_IN.ALL计数器，发现：

CPUID，RDRAND, RDSEED三条指令会使用到LFB，可以泄露他们返回的结果。RDRAND, RDSEED指令用于产生随机数，可能用于密码领域，信息泄露有较大危害。