云基础设施之硬件安全威胁

	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年报告 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、SRBDSMLPDS TAA、MFBDS、MDSUM、CACHEOUT、Fallout等等。此外，ARM也受Spectre和Meltd own影响，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武器化工具 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，数据从L1cache写入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 可以泄露他们返回的结果RDRANDRDSEED 指令用于产生随机数 可能用于密码领域 信息泄露有较大危害。 4. BMC安全威胁 BMC Baseboard Management Controller 基板管理控制器支持行业标准的 IPMI 规范。该规范描述了已经内置 到主板上的管理功能。这些功能包括：本地和远程诊断 控制台支持 配置管理 硬件管理和故障排除。 攻击面包括： •    web •    IPMI等网络服务 •    固件升级 •    Host主机 4.1 固件升级漏洞 BMC basecode厂商AMI将代码给到服务器厂商 服务器厂商在此基础上二次开发。 如果 AMI的代码有漏洞 服务器厂商的BMC还会安全吗？ 4.1.1 固件提取 1、找到$MODULE$ … root地址为0x350000 2、对应的0x360000 即为根文件系统 3、可以直接mount 到目录 进行读取 修改根文件系统。 4.1.2 刷写固件 1、提取固件以后 就可以对固件里面的程序进行分析。发现有一个flasher进程负责固件的升级。 2、对flasher进程进行分析 发现其对于固件的校验很弱 可以被绕过 可以烧写一个恶意的 固件从而控制BMC和主机。 POC: 由此获得了厂商致谢以及两枚CVE: CVE-2020-26122 CVE-2020-24943 4.2 web漏洞 某厂商BMC web登录接口 利用漏洞 可以通过网络直接拿到BMC后台shell权限 进一步控制HOST主机 5. 网卡安全威胁 攻击面： 1，固件：实现在固件里面的ASF, AMT等远程开机协议；BOOTROM 无盘 系统网络加载系统镜像；IPMI等管理协议； 2、驱动：Host和网卡交互 交换数据； 案例： 1、博通网卡固件任意代码执行 https://www.ssi.gouv.fr/uploads/IMG/pdf/csw-trustnetworkcard.pdf 2、特殊网络包导致intel网卡拒绝服务 https://www.intel.com/content/www/us/en/security -center/advisory/intel-sa-00063.html 6. 硬件威胁及防御方案 硬件漏洞给云基础设施带来的威胁远超出我们的想象 信息泄露 提权 拒绝服务 远程代码执行 甚至完全控制 影响范围广 供应链复杂 修复周期长 修复方案或影响正常业务 这对我们的防护提出了更高要求。 硬件威胁防御方案不是做好一个点就可以的 需要全方位防御措施 包括：监测预警 权限管理 入侵检测 漏洞扫描 漏洞挖掘 及时修复 需多方紧密配合 缺一不可 才能保障业务安全。