[2022.12.30][CCS 2022] CETIS: Retrofitting Intel CET for Generic and Efficient Intra-process Memory Isolation

Seminar

Source: https://dl.acm.org/doi/pdf/10.1145/3548606.3559344 Authors: Mengyao Xie Chenggang Wu Yinqian Zhang Download Note: https://jbox.sjtu.edu.cn/l/x1tMOM Contributor: ydh Overview 进程内隔离是一种经典的控制错误和恶意代码的方法，可以阻止控制流劫持攻击包括，代码注入攻击、代码重用攻击、data-only攻击。已有研究具体提出了code-pointer integrity(CPI)，shadow stacks，CFIXX这些保护方案。这些技术保护进程中隔离区域中的敏感指针、返回地址或虚指针，并只允许可信代码访问这些区域。 已有的进程内隔离的方法可以分为两大类：一类是基于地址的隔离，这类方法通常对不可信代码的每个内存访问都会进行边界检查，如SFI。这类方法通常是基于软件实现会导致服务代码的体积增大，并且大量的插桩会导致巨大的性能开销；第二类也是近期研究关注的基于域的隔离，这类方法通过控制内存访 问权限隔离内存。当可信代码访问就开启访问权限，结束后关闭权限。为了提高效率研究者利用了很多硬件特性，VMFUNC，MPK，SMAP，其中基于MPK的方案被广泛研究，因为它不依赖于虚拟化技术。但是当权限需要频繁切换时会导致这种方案也会有高性能开销，如CPI和shadow stack。 本文提出了一种新的内存隔离机制CETIS，利用了Intel新引入的Control-flow Enforcement Technology(CET)中的shadow stack(SHSTK)机制。目前SHSTK仅仅是用来保护返回地址的完整性，并不支持通用的内存隔离，CETIS拓展了它的功能使其支持一般的内存隔离。

READ MORE

[2022.09.30][USENIX Security 2022] A Hardware-Software Co-design for Efficient IntraEnclave Isolation

Seminar,

Source: https://www.usenix.org/system/files/sec22-gu-jinyu.pdf Authors: Jinyu Gu, Bojun Zhu, Mingyu Li, Wentai Li, Yubin Xia, Haibo Chen Download Note: https://jbox.sjtu.edu.cn/l/X19mia Contributor: ydh Overview 现在的SGX程序为了最大程度地减少代码重构的工作量，避免应用程序分块带来的性能损失，现在流行的编程趋势是在单个SGX Enclave中使用第三方库或者是LibOSes运行整个应用程序。但这会使得TCB膨胀并危及敏感代码/数据。一旦三方库或是LibOS中存在漏洞，都会威胁到整个enclave的安全性。 为了解决这个问题，现在存在几种解决方法： 将一个程序拆分并放到不同的相互独立的enclaves中（Ryoan，Panoply），这种方式利用了不同enclave之间的隔离性，但是很明显在enclave交互过程中有很大的overhead。 于是就有了在enclave内部的隔离（CHANCEL，Spons & shields，Occlum，Nested Enclave）。但是这些方案都在灵活性和效率上存在限制。前三种是通过对enclave内存访问指令插桩的方法（软件方法）来做强制性的边界检查来实现的。插桩的方式会带来在运行时不可忽略的开销，并且 也会增大代码的体积。Nested Enclave使用了硬件拓展的方式，将它分为inner和outer enclave，但是inner和outer之间的交互边界的overhead依然很大。 本文的工作是设计一个有效率且安全的intra-enclave隔离方案。使用Intel MPK这个硬件特性对enclave内部的地址空间做细粒度的划分以完成隔离。

READ MORE

[2022.06.23][USENIX Security 2022]MORPHUZZ: Bending (Input) Space to Fuzz Virtual Devices

Seminar,

Source: https://www.usenix.org/system/files/sec22summer_bulekov.pdf Authors: Alexander Bulekov Bandan Das Stefan Hajnoczi Manuel Egele Download Note: https://jbox.sjtu.edu.cn/l/X19YQI Contributor: ydh Overview 整个云生态系统的安全性依赖于hypervisor在客户vm和主机系统之间提供的隔离保证。为了vm与其环境通信，hypervisor提供了大量虚拟设备。如果这些虚拟设备中存在bug和漏洞将会破坏hypervisor提供的隔离性保障。例如，利用虚拟设备中的漏洞可以完成虚拟机逃逸，它允许在不受信任的客户机中的攻击者破坏底层hypervisor并在VM的安全范围之外执行代码。这篇文章提出了一种通用方法，利用对hypervisor设计的洞察，结合覆盖引导模糊测试来找虚拟设备实现中的bug。这种方法不需要对虚拟设备有专业的知识，作者应用这个工具在QEMU和bhyve上的33个不同的虚拟设备，发现了61个bug，22个已经被修复，9个给了CVE。

READ MORE

A Systematic Look at Ciphertext Side Channels on AMD SEV-SNP

Seminar,

Author: Mengyuan Li∗，Luca Wilke∗，Jan Wichelmann，Thomas Eisenbarth，Radu Teodorescu，Yinqian Zhang Conference: S&P 2022 Paper Link: https://ieeexplore.ieee.org/document/9833768 Note Link: https://jbox.sjtu.edu.cn/l/D1EiAo Contributor: pdh Overview 基于硬件的内存加密方案例如Intel SGX和AMD SEV为程序提供了可信的执行环境，然而21年Security的一篇文章揭露了CipherLeaks攻击，它能够监控特殊VMSA页中密文的变化，通过在泄露虚拟机进行上下文切换时泄露寄存器中的数据，攻破了最新的 时间下的密码学方法的实现，包括OpenSSL中的RSA和ECDSA。 本文对TEE中（具体来说时SEV中）密文的旁路进行了一个系统性的研究，结果显示，虽然密文泄漏攻击只针对VMSA页面，但一般的密文侧通道攻击可能利用任何内存页面的密文泄漏，包括内核数据结构、堆栈和堆的页面。因此，AMD现有的应对方案，即一个固件上的补丁，对VMSA上的密文嵌入随机化，是无效的。AMD SEV内存加密的泄露的根本原因，即使用未经过身份验证的加密模式和对加密内存密文的无限制读取访问依然是一个未解决的问题。针对这一源于硬件设计上的漏洞，本文提出了一套基于软件的对策，包括对系统内核以及密码库的补丁。

READ MORE

[2022.06.15] [S&P 2022] vSGX: Virtualizing SGX Enclaves on AMD SEV

Seminar,

Author: Shixuan Zhao, Mengyuan Li, Yinqian Zhang, Zhiqiang Lin Conference: S&P 2022 Paper Link: https://www.computer.org/csdl/proceedings-article/sp/2022/131600a687/1A4Q3q3W28E Note Link: https://jbox.sjtu.edu.cn/l/01EAPB Contributor: pdh Overview 现如今对可信执行环境的需求加速了可信硬件的发展，然而在不同架构下有着不同的可信硬件的实现方式，导致开发者在开发时还要针对架构进行不同程度的开发，兼容性很差。本文提供了vSGX，用于在AMD SEV的环境下虚拟一个SGX enclave，使得AMD架构能够兼容SGX的代码。其问题的关键在于SGX代码有一些额外的指令集（ENCLS和ENCLU），需要在AMD平台下对这些指令进行模拟，并且利用SEV虚拟机创建一个类似于SGX的地址空间和内存执行环境。具体来说，vSGX可以被视作一个被插入到SEV虚拟机中的SGX硬件模块，其核心思路就是利用SEV提供的虚拟机保护机制创建一个可信执行环境，用来移植SGX。这样，SGX enclave的代码和数据的机密性由AMD的内存加密引擎（Memory Encryption Engine, MEE）来保证，完整性由基于AMD SEV的远程认证设计出的认证服务来保证。移植了SGX enclave的虚拟机被称为enclave VM (EVM)，而运行不可信app的虚拟机则被称为app VM (AVM)。因此，通过本文的设计，vSGX在AMD平台下达到了和Intel SGX相似的安全性，并且有着合理的额外开销。 虽然这个在AMD架构上虚拟化SGX的想法非常直观，但是完成这个想法需要面对几个不平凡的挑战： 如何在AMD SEV中插入SGX的指令； 如何处理那些需要跨越EVM和AVM的操作（例如EENTER和EEXIT）； 如何处理跨EVM和AVM的内存访问； 如何处理AVM的OS中存在的不可信的代码，甚至是恶意的hypervisor； 如何去实现远程认证。 本文分析了vSGX的安全性，并且讨论了本文的设计是如何达到和原生SGX可比较的安全级别。同时，本文对vSGX的运行性能进行了评估，运行了一个benchmark集合以及现实世界中真实的SGX应用。结果显示一些SGX的指令确实会显著降低vSGX的运行性能（例如EENTER和EEXIT），但是这些只有那些拥有很多ECall和I/O操作的程序中才会显示出来。本文通过对真实世界SGX应用进行评估的结果显示，vSGX的额外性能开销是可以接受的。

READ MORE

[2022.03.26] [CCS 2021] A Formally Verified Configurationfor Hardware Security Modules in the Cloud

Seminar

Author: Riccardo Focardi，Flaminia L. Luccio Conference: CCS 2021 Paper Link: https://arxiv.org/abs/2109.13631 Note Link: https://jbox.sjtu.edu.cn/l/r1Xn25 Contributor: pdh Overview 硬件安全模块（Hardware Security Modules, HSM）是一种可信的硬件，用来在复杂的系统中执行一些敏感的操作，主要是针对密钥的存储。通常人们在使用服务器时不会讲密钥直接存储在磁盘中，而是被保障在HSM的安全范围之中。HSM长期被用于保护SSL/TLS的加密密钥，以便实现安全的网路通信。近年来，HSM在其他领域有了更多的应用，例如金融、政府数据、主机游戏、区块链交易等。（介绍视频：https://www.youtube.com/watch?v=hOzkr66G1jw ）HSM具有防止数据被篡改的硬件特性，一般来说它会向外部提供一些API，方便使用者完成密钥的存储、封装、加解密等操作。最通用的API为PKCS#11，或者叫Cryptoki。 然而在过去二十年的研究中，发现其存在一些API级别的漏洞，例如$\textit{wrap-then-decrypt}$ attack，其存在漏洞的主要原因在于用来封装的密钥和被封装的密钥没有被区分开，同时还存在封装密钥多次使用的问题。后续有一些adhoc的工作来修补这一漏洞，在API中提供了wrap_with_trusted这一接口，但这个问题并没有受到广泛的关注。最新的PKCS#11的文档甚至还保留了之前不安全的wrap接口，而并未在文档中提到它的不安全性。还有一些其他的adhoc的工作，但是这些工作并不完整，没有对完整的API接口进行修改，只是设立了一个API的安全子集。随着近年来HSM在云上的使用越来越广泛，这些安全问题需要更加被注意。 本文提出第一次提出了针对HSM的配置（configuration，不太理解这个词，可能用standard更好理解？），通过对HSM的使用者的角色划分来防止那些有漏洞的API被攻击者利用导致密钥的泄露。本文将使用者划分成三种不同的类型： Normal Users：(𝑖)他们可以使用完整的API，以最大限度地提高兼容性；(𝑖𝑖)他们不能利用应用API级别的攻击来泄露敏感密钥，因为他们是最容易受到攻击的HSM用户。事实上，攻击者可能会利用生产应用程序中的漏洞来获得对HSM API的访问权限。 Key Manager：这些用户利用标准的API来管理系统中的密钥。他们负责处理将用于包装其他敏感密钥的受信任密钥。这些钥匙的生命周期非常微妙。例如，它们不应该被包装在其他密钥下，也不应该被允许加密或解密数据。这样的用户通常处于更高的特权级别下，但是他们不能像NU一样开发普通的应用程序。 Security Officer：安全官员是遵守PKCS#11标准的特殊用户，却无法访问完整的API。因此，SO主要执行管理任务，例如创建其他HSM用户和将密钥标记为受信任。具体来说，SO只能将由KM生成的密钥标记为trusted。同样的，他们不能像MU一样开发普通的应用程序。 直觉上来说，当讲trusted keys（由KM或者SO创建）与其他密钥区分开始，被封装的密钥就无法被攻击者获得。但是这个问题的难点在于要严格定义各种权限用户的能力，使得整个系统处于一个安全的状态。本文的角色分离基于一个重要假设，即一个用户生成的密钥可供其他HSM用户使用，但密钥管理操作(如属性更改)将仅允许密钥所有者使用。本文将展示这种形式的温和访问控制已在实际的云HSM解决方案中实现。 Contribution (1) 本文第一次提出了通过对用户角色的划分来构建安全的PKCS#11。具体来说就是新增了两种特别的用户：Key Manager和Security Officer来创建trusted keys。 (2) 基于用户角色的划分，本文提出了第一个实际可用的HSM Configuration，它不需要对PKCS#11作任何的修改和限制，并且具有很好的兼容性。 (3) 本文展示了如何将这些规则直接应用于AWSCoudHSM，它提供了对用户和密钥的适当访问控制。 (4) 本文对PKCS#11的核心部分进行了形式化建模，并且用其区队提出的安全配置规则进行形式化的验证。本文使用了Tamarin这一形式化工具，用来验证敏感的密钥永远不会泄露给普通的用户。整个证明过程是全自动化的。

READ MORE

[2022.04.27] [NDSS 2020] HFL: Hybrid Fuzzing on the Linux Kernel

Seminar,

会议: NDSS’20 链接: https://www.ndss-symposium.org/wp-content/uploads/2020/02/24018-paper.pdf 作者: Kyungtae Kim, Dae R. Jeong, Chung Hwan Kim, Yeongjin Jang, Insik Shin‡ Byoungyoung Lee Contributor: fhr abstract 混合Fuzzing是一种结合模糊测试和符号执行的程序分析技术，在漏洞挖掘领域有良好的前景。模糊生成和精确生成测试用例二者互为补充，能够克服各自的局限性。然而，由于内核所具有的特性，直接将Hybird Fuzzing应用到Kernel上存在如下挑战： （1）由系统调用参数决定的间接控制流分析 （2）系统调用及参数之间隐式依赖关系分析 （3）系统调用参数的嵌套类型推断 本文基于Syzkaller和S2E(binary lifting & klee)提出HFL这一面向kernel的混合fuzzing工具，并提出三项技术来解决上述问题。 （1）通过编译期的分析优化，将间接跳转转换为直接跳转。 （2）通过静态指针分析，选择性地符号化数据变量并推断syscall之间的依赖关系。 （3）根据处理syscall参数的方式不同，在运行时推断嵌套参数类型。 实验结果表明，HFL能够高效地将混合fuzzing技术引入内核的安全分析中。HFL的代码覆盖率高于Moonshine、Syzkaller、TriforceAFL等工作，并且发现了24个未知漏洞。

READ MORE

[2022.05.11][PLDI2021]BlankIt Library Debloating:Getting What You Want Instead of Cutting What You Don’t

Seminar

Source: https://dl.acm.org/doi/pdf/10.1145/3385412.3386017 Authors: Chris Porter, Girish Mururu, Prithayan Barua, Santosh Pande Download Note: https://jbox.sjtu.edu.cn/l/V1qUSJ Contributor: fy Overview 现代软件开发在很大程度上依赖于库，许多库是为支持大量功能而构建的。然而，单个应用程序中，可以只使用少量的库功能。例如，开发一个安卓应用，使用机器学习和人工智能相关工具库，以及Web框架。尽管这些库和框架本身可能非常大，但在实际开发中只用到它们的一小部分API是很常见的。Debloat就是去膨胀，也就是减少可用于构建攻击gadget的代码量，从应用程序或库中删除不需要的代码或死代码。本文采用动态的debloat方法，仅在函数需要被使用时进行加载，显著地削减了函数总量（97%），增强了程序的安全性。

READ MORE

[2022.03.30] [USENIX Security 2018]Debloating Software through Piece-Wise Compilation and Loading

Seminar

Source: https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-quach.pdf Authors: Anh Quach, Aravind Prakash, Lok Yan Download Note: https://jbox.sjtu.edu.cn/l/j1XGKo Contributor: ydh Overview 代码重用在软件开发的过程中是必不可少的，开发者会把代码打包到一个重用代码模块中，如共享库为不同的应用程序提供接口。但是共享库内容很多，一个应用程序不会用到里面全部的代码。这些无关的代码自身可能包含bug和漏洞，扩大了整个攻击面，也为代码重用攻击提供了便利。静态死代码消除是一种静态分析技术，用于识别未使用的代码路径，并将它们从最终的二进制文件中删除，在编译期间使用的这种方法是减少代码膨胀的有效方法。但是，这种方法对链接库不太适合，动态链接的库无法删除死代码，因为它是预先构建好，运行时加载到内存中的，加载器也不会对它做检查；静态链接库也很麻烦，需要重新编译且不好管理。这篇文章设计了一个piece-wise的编译器和加载器做debloating，有效地减少了链接库的体积。

READ MORE

[2022.05.25] [USENIX Security 2021] Understanding Malicious Cross-library Data Harvesting on Android

Seminar

Understanding Malicious Cross-library Data Harvesting on Android 作者：Jice Wang, Yue Xiao, Xueqiang Wang, Yuhong Nan, Luyi Xing, Xiaojing Liao, Jinwei Dong, Nicolas Serrano, Haoran Lu, Xiaofeng Wang, Yuqing Zhang 单位：University of Chinese Academy of Sciences, Indiana University Bloomington, Purdue University, Xidian University, Hainan University 出处：USENIX Security 2021 原文：https://www.usenix.org/system/files/sec21-wang-jice.pdf Contributor: FRH 笔记：https://jbox.sjtu.edu.cn/l/E1cD9I 移动应用通常会集成第三方库(用于数据分析、广告、应用变现等)，在丰富其功能的同时也带来了安全威胁。已有的工作都关注三方库从应用中收集隐私数据的行为，这篇文章中作者提出一种新的攻击方式Cross-Library Data Harvesting (XLDH)，即恶意的三方库从应用集成的其他厂商的库中收集数据，例如，恶意三方库可以调用Facebook […]

READ MORE