【机密计算顶会解读】04：EncalveFuzz——用于查找 SGX 应用中的漏洞_enclavefuzz: finding vulnerabilities in sgx applic-优快云博客

本文链接：https://blog.youkuaiyun.com/WhiteLab_Y/article/details/145904599

导读：本文介绍EnclaveFuzz，其能够利用模糊测试技术，通过自动化异常输入检测SGX应用中的漏洞。

原文链接：EnclaveFuzz: Finding Vulnerabilities in SGX Applications - NDSS Symposium

EnclaveFuzz: Finding Vulnerabilities in SGX Applications（NDSS’24）

一、研究背景

Software Guard Extensions(SGX) 是Intel提出的一种进程级的可信执行环境（TEE）解决方案，其提供了一系列指令集扩展，用于支持名为飞地（Enclave）的可信执行环境，Enclave中的数据与代码由硬件设备进行加密，与外部用户态进程或高权限进程，如操作系统，虚拟机管理程序（Hypervisor）隔离，防止了Enclave中内存被外部进程的访问。对于Enclave中程序的安全性，除了受到老生常谈的内存破坏引入的安全问题，Enclave特殊的威胁模型，将产生SGX独有新的攻击面，例如Enclave程序访问外部不可信内存时可能导致的Time-of-Check-Time-of-Use(TOCTOU)与恶意分配0地址页表后加剧了空指针解引用(Null-Pointer Dereference)漏洞的危害。为了保证Enclave中程序的安全性，对Enclave中代码的自动化漏洞挖掘具有重要意义。

模糊测试（Fuzzing）是一种自动化漏洞挖掘技术，已经广泛应用在对各类软件系统的漏洞挖掘当中，并且在诸如Linux操作系统，V8引擎等大型软件中找出了数以千计的漏洞。EnclaveFuzz利用模糊测试技术以自动化寻找SGX应用中的漏洞。

二、现状分析

SGX应用分为宿主应用和enclave两部分。Enclave具有私有的可信代码与数据地址空间，即使两者共享相同的虚拟地址空间，宿主应用无法访问任何encalve中的内存，enclave则可访问宿主应用的内存，但无法运行宿主应用中的代码。两者之间只能通过调用特别的指令来进行交互，例如宿主应用通过ECALL进入enclave，Encalve通过OCALL回到宿主应用。因此，对于enclave而言，输入来自以下三个维度: 1.ECALL函数的参数。2.OCALL函数的返回值。3.对宿主应用非可信内存的访问。

开发者借助Enclave Definition Language(EDL)为ECALL和OCALL声明接口，SGX SDK将根据此来自动化的生成宿主应用和encalve交互的桥接代码，其中会包含对于调用ECALL与OCALL时参数与返回值的检查代码，以检查enclave输入的合法性，通过检查后才会真正执行enclave中的代码。

已有对SGX应用的模糊测试方案，主要有以下三个方面的缺陷：

SGXFuzz和FuzzSGX，缺少了对enclave合法输入的认知，导致生成了大量无法通过SDK生成代码检查的无效种子。其次，缺少了enclave第三个维度输入对非可信内存的变异，难以发现由访问非可信内存导致的漏洞。
模糊测试中至关重要的漏洞检测模块（Oracle），决定了模糊测试可探索的漏洞种类，而已有工作大多集中在对enclave中内存破坏漏洞的发掘，缺少了对SGX特有攻击的探索。
Enclave的创建与销毁，宿主程序与enclave进行交互时的上下文切换将会引入多余的时间开销，阻碍了模糊测试的速率。

三、应对设计

整体模糊测试流程如图。首先，通过预处理的多维度结构感知阶段分析EDL文件提取出ECALL, OCALL等参数信息，用于生成Harness与合法的enclave输入；其次，通过优化后的SGX SDK，模拟enclave环境，提高模糊测试的速度；最终，在测试目标代码中添加对内存破坏与SGX独有漏洞的检测代码，报告最终触发的漏洞。

多维度结构感知：从EDL中对ECALL,OCALL参数与返回值的定义出发，得到显性的数据类型与方向信息，递归分析提取结构化类型中嵌套的数据类型。对于隐性的数据类型，采用从类型定义中匹配的方式确定，而对于不确定的数据传递方向信息，将其视为enclave的输入根据随机化的长度生成内容，并以一定可能性选择0地址作为指针参数进行测试。本质上变异来讲，这部分确定了EDL中规定的enclave的安全边界，依赖先验的漏洞知识与sanitizer的报告从enclave的三个输入维度生成绕过SDK检查边界的种子进行测试。
优化后的SGX SDK：为了避免维护enclave自身资源所需要的多余上下文切换等开销，修改SGX SDK使生成的运行在enclave的桥接代码与enclave代码编译为共享库文件链接至宿主应用。通过改写Sanitizer中的shadow map对enclave私有堆栈区域与非可信内存隔离，从而得到不需要SGX硬件支持的虚拟enclave运行环境。
漏洞检测：总结了SGX可面临的四种漏洞：越界访问，悬挂指针解引用，0地址解引用和TOCTOU漏洞。分别为这四类漏洞设计了相应的漏洞检测规则。

四、技术解析

EnclaveFuzz的架构如上图，主要包含预处理生成、LibFuzzer和虚拟enclave三大模块。

预处理模块的实现通过扩展SGX的Edger8r工具来分析EDL中与ECALL和OCALL相关的信息，主要包含数据类型信息、指针类型数据大小与传递方向、参数间相关性等。通过编写LLVM IR Pass来收集源代码中结构体与嵌套类型数据信息，同时生成包装ECALL和监控OCALL的模糊测试harness，根据收集到的信息为enclave的接口准备变异数据。
Fuzzer模块则使用了LibFuzzer的模糊测试引擎，通过dlopen加载优化后的enclave共享库，创建虚拟enclave，依赖预处理模块收集的信息不断变异与enclave交互的ECALL参数内容与OCALL返回值进行测试。同时通过对Load指令插桩以确定对非可信内存区域的访问，通过TOCTOU sanitizer的指导进行测试。
消除SGX SDK模拟模式中的enclave内存管理，上下文切换等多余开销，进入与退出enclave采用函数表的形式代替，以生成虚拟的enclave。漏洞检测SGXSan基于AddressSanitizer实现对越界访问，悬挂指针、0地址解引用漏洞的检测，借助对load指令和比较指令的def-use chain来构建TOCTOU sanitizer。

五、验证评估

文章在Intel Xeon(R) 8358 CPU，1024G内存的环境下对20个来自Intel和第三方开发者的开源SGX应用进行了测试，每个enclave程序测试24小时，并重复测试三次。

主要对以下问题进行了评估：

5.1 是否Enclave能在实际的enclave应用中发现新的漏洞，特别是SGX独有的漏洞？

在14个应用中一共发现了162个bug，在TaLoS发现了96个bug，而其对应的ECALL数量也是最多的有207个，也从侧面说明了enclave的暴露的接口越多，可能会引入更多的漏洞，也为enclave开发者提个醒，在对自己代码安全性不是特别有信心时，可以尽量减少enclave的接口。

5.2 是否结构感知方法提高了模糊测试的代码覆盖率？

EnclaveFuzz在代码覆盖率、输入有效性和bug检测数量上，较之于SGXFuzz，都有一个不错的提升。

5.3 是否多维度的输入帮助发现了更多的漏洞？

为了验证多维度输入可以覆盖更多的攻击面与寻找到更多的漏洞，文章分别对使用了三个维度的EnclaveFuzz，减少对非可信内存区域测试的Fuzzer-NonSan和仅考虑ECALL一个纬度的Fuzzer_1D进行了相关实验，Fuzzer_NoSan和Fuzzer_1D结果相似说明发现OCALL的漏洞并不是特别多，而对于非可信内存区域访问造成的TOCTOU漏洞也存在着不少。