gossipeditor – Page 2 – GoSec@CS.SJTU

[2022.11.25][S&P 2021]Android Custom Permissions Demystified From Privilege Escalation to Design Shortcomings

Feb 10, 2023gossipeditorSeminar

Source: https://ieeexplore.ieee.org/document/9519385 Authors: Rui Li, Wenrui Diao, Zhou Li, Jianqi Du, Shanqing Guo Download Note: https://jbox.sjtu.edu.cn/l/D1AmXQ Contributor: zyt Overview 本文对Android的自定义权限机制进行了系统性的研究，发现了由于权限机制设计的缺陷，当一些特定行为触发时，会导致权限提升的漏洞，使得恶意应用程序可以在未经用户同意的情况下获得危险的系统权限，并进一步访问未经授权的平台资源。为了全面地测试出与Android自定义权限机制有关的漏洞，作者设计了一个模糊测试工具CuPerFuzzer，用于探测哪些特定指令序列（包含自定义权限设定、修改，操作系统更新等）能够导致权限提升漏洞。实验结果表明，CuPerFuzzer发现了2384个有效测试用例，以及30条能触发权限提升漏洞的关键路径。通过对关键路径的总结，作者发现了Android权限框架中的几个设计缺陷，包含悬空的自定义权限、不一致的权限-组映射、自定义权限提升和不一致的权限定义，对应了四个高危CVE。

[2022.07.20][S&P 2022]Augury: Using Data Memory-Dependent Prefetchers to Leak Data at Rest

Feb 9, 2023gossipeditorSeminar

Source: https://www.cs.tau.ac.il/~mad/publications/sp2022-augury.pdf Authors: Vicarte J S, Flanders M Download Note: https://jbox.sjtu.edu.cn/l/S19GoE Contributor: fy 本文主要通过利用瞬态执行漏洞构建微架构侧通道攻击，泄露内存中的不依赖投机执行的数据（data at rest）。大部分微架构侧通道攻击只能在运行时泄露数据（data in use），通过利用CPU中的微架构，比如预测执行时的架构寄存器，数据被读入这样的寄存器，由一条指令以操作数相关的方式影响了硬件的使用情况，通过侧通道泄露。可以通过常量时间编程技术来抵御。本文则针对更广泛的情况，也就是不会依赖投机执行的数据。这种提升是由于CPU增加了更多的微架构，其中一种是Data Memory-dependent prefetcher。DMP又被称作间接内存prefetcher，位于内存系统中，被设计用来预取不规则的地址模式。会根据memory中的值，例如指针解引用等，直接取到相应值存入cache中。由于秘密数据只在cache中，没有进入CPU core，常量时间编程技术对其无效。利用这一微架构可对内存发起越界读取（平均准确率为92.0%），阻碍投机负载硬化、通过Prime+Probe检索泄露地址和破坏ASLR等攻击。

[2022.11.18] [CCS 2022] SymLM: Predicting Function Names in Stripped Binaries via Context-Sensitive Execution-Aware Code Embeddings

Feb 9, 2023gossipeditorPhoto

作者：Xin Jin, Kexin Pei, Jun Yeon Won, Zhiqiang Lin 单位：The Ohio State University, Columbia University 出处：CCS 2022 原文：https://dl.acm.org/doi/pdf/10.1145/3548606.3560612 Contributor: FRH 笔记：https://jbox.sjtu.edu.cn/l/h14FR3 预测被去除符号信息的二进制文件(stripped binary)中的函数名对许多具体的安全应用都有帮助，包括恶意软件分析、漏洞识别、二进制代码加固等。作为具体的例子，Mandiant等安全公司投入大量资源开发各种逆向工具用于符号恢复、函数标注、二进制代码匹配等，从而帮助开发人员更高效地分析恶意软件的功能，并进一步追溯其来源。然而，构建有意义的函数名是非常有挑战的任务。函数名提供了函数行为的高层次总结，预测函数名需要理解函数的具体操作，并将其组合、映射到自然语言中。然而，不同的编译器方言(idioms)、优化、混淆以及不同操作系统的ABIs、不同架构的硬件规格导致相同语义的代码存在多样的二进制表示，为预测带来困难。这篇文章中，作者提出SYMLM(Symbol name prediction and binary Language Modeling)这一框架，利用神经网络技术，通过对调用上下文和指令的联合建模来理解函数语义，最终实现预测。作者在27个流行开源项目(1,431,169个函数)上针对4种不同的架构(x64、x86、ARM和MIPS)、4种优化(O0-O3)、4种混淆进行实验。SYMLM相较于SOTA工具在精度、召回率和F1-score上分别有15.4%、59.6%和35.0%的提升。同时，作者的消融实验证明其框架各个组件的必要性。最后，作者进行案例分析，进一步证明了SYMLM可以用于分析实际的固件。

[2022.09.16] [TSE 2021] Research on Third-Party Libraries in Android Apps: A Taxonomy and Systematic Literature Review

Feb 9, 2023gossipeditorPhoto

作者：Xian Zhan, Tianming Liu, Lingling Fan, Li Li, Sen Chen, Xiapu Luo, and Yang Liu 单位：The Hong Kong Polytechnic University, Nankai University, Monash University, Tianjin University, Nanyang Technological University 出处：TSE 2021 原文：https://ieeexplore.ieee.org/document/9542854 Contributor: FRH 笔记：https://jbox.sjtu.edu.cn/l/J19G8N 三方库在安卓应用中的使用非常广泛，在提升应用功能的同时也带来了一些安全威胁，因而受到学术界大量的关注。目前还没有系统性的研究对已有的工作进行总结，为此，这篇文章对安卓三方库研究进行了第一次系统性的文献综述。作者收集了2012到2020年发表的74篇安卓三方库相关的论文，对这些研究进行了分类，总结了目前三方库分析的解决方案、限制、挑战以及未来可能的研究方向。

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

Feb 4, 2023gossipeditorSeminarisolation

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拓展了它的功能使其支持一般的内存隔离。

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

Feb 4, 2023gossipeditorSeminarisolation, SGX

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内部的地址空间做细粒度的划分以完成隔离。

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

Feb 4, 2023gossipeditorSeminarFuzzing, hypervior

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。

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

Sep 22, 2022gossipeditorSeminarSEV, System Security

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内存加密的泄露的根本原因，即使用未经过身份验证的加密模式和对加密内存密文的无限制读取访问依然是一个未解决的问题。针对这一源于硬件设计上的漏洞，本文提出了一套基于软件的对策，包括对系统内核以及密码库的补丁。

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

Jun 14, 2022gossipeditorSeminarSEV, SGX

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的额外性能开销是可以接受的。

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

Jun 14, 2022gossipeditorSeminarHSM

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这一形式化工具，用来验证敏感的密钥永远不会泄露给普通的用户。整个证明过程是全自动化的。