Seminar – Page 2 – GoSec@CS.SJTU

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

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

Jun 14, 2022gossipeditorSeminarFuzzing, vulnerability detection

会议: 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个未知漏洞。

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

Jun 14, 2022gossipeditorSeminar

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%），增强了程序的安全性。

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

Jun 14, 2022gossipeditorSeminardebloat

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，有效地减少了链接库的体积。

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

May 25, 2022gossipeditorSeminar

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 […]

[2022.02.16] [ISSTA 2021] Semantic Matching of GUI Events for Test Reuse Are We There Yet？

Mar 16, 2022gossipeditorSeminarAndroid

Source: https://doi.org/10.1145/3460319.3464827 Authors: Leonardo Mariani, Ali Mohebbi, Mauro Pezzè, Valerio Terragni Download Note: https://jbox.sjtu.edu.cn/l/g1nobP Contributor: zyt Overview UI测试重用（UI Test Reuse）是目前在UI自动化测试领域的研究热点，旨在解决UI自动化测试中测试用例缺乏语义信息，难以检测系统功能上正确性的弊端。其方法是在一个源app中人工生成一个有效的UI事件序列（例如：完整的注册过程），并在另一个目标app中，通过语义匹配的方式，确定源事件在目标app上的对应事件，从而在目标app上自动生成一个有效的测试用例。语义匹配是UI测试重用的重要模块，其目的是通过提取UI上的信息，分析UI表达的语义含义，从而提高事件匹配的准确性。本文针对UI测试重用中的子模块——语义匹配，进行系统性地评估分析。整个语义匹配系统被分为四个部分：语料库，词嵌入算法，事件描述符提取和语义匹配算法。作者对四个部分所有的252种配置可能进行实验，并与baseline进行对比，分析语义匹配系统各个组成部分对系统的影响。

[2022.03.03] [ICSE 2022] PROMAL: Precise Window Transition Graphs for Android Synergy of Program Analysis and Machine Learning

Mar 3, 2022gossipeditorSeminar

作者：Changlin Liu, Hanlin Wang, Tianming Liu, Diandian Gu, Yun Ma, Haoyu Wang, Xusheng Xiao 单位：Case Western Reserve University, Monash University, Peking University, Beijing University of Posts and Telecommunications 出处：ICSE 2022 原文：https://engineering.case.edu/groups/xusheng-xiao/sites/engineering.case.edu.groups.xusheng-xiao/files/docs/promal_icse_cr.pdf Contributor: FRH 笔记：https://jbox.sjtu.edu.cn/l/I1oHrr 利用自动化分析技术提高移动应用的质量和可靠性是非常重要的。WTG(window transition graph)是自动化分析技术的关键组件。在WTG中，点(node)代表窗口，边(edge)代表窗口之间的跳转。已有的研究工作通过静态或动态分析的方式构建WTG，但在准确度上仍然存在不足。静态分析采用over-approximation的设计导致误报，产生不可能的跳转，而动态分析受到覆盖率问题的影响。为此，作者提出"tribrid analysis"方法PROMAL，协同地组合了动静态分析技术和机器学习技术为应用构建WTG。PROMAL主要分为两个阶段: 首先使用静态分析构建WTG，结合动态分析对WTG中的跳转进行验证对于大量动态分析无法验证的跳转，提取窗口的信息作为特征，利用机器学习技术预测跳转是否成立。 PROMAL的精度为90.18%，回归率为79.69%，F1-score为82.82%。相比于GATOR(46.24%)、GATOR和PALADIN组合(61.93%)都有更好的表现。

[2022.02.23] [ESEC/FSE 2021] Vet: Identifying and Avoiding UI Exploration Tarpits

Mar 2, 2022gossipeditorSeminarAndroid

Source: https://dl.acm.org/doi/abs/10.1145/3468264.3468554 Authors: Wenyu Wang, Wei Yang, Tianyin Xu, Tao Xie Download Note: https://jbox.sjtu.edu.cn/l/910ku4 Contributor: syjh Overview 作者的实验表明表明，现有的移动 UI 测试工具很容易出现exploration tarpit。这些工具会在很长一段时间内卡在一小部分应用程序功能上。比如说，测试工具在测试某个APP时过早注销账户，后续测试时就容易卡在探索应用程序的登录前功能，而不是其主要功能。当然如果只是登录，测试者可以手动设定规则，但是这种exploration tarpit类型很多，没有一个统一的方法。本文提出自动测试工具Vet，它针对两个常见的exploration tarpit制定了两个算法判定测试工具是否进入了exploration tarpit。Vet可以引导测试框架避免进入exploration tarpit或者从中恢复，因此Vet可以提高代码覆盖率。