How to debug wasm compiled by wasi-sdk?
如何调试支持wasi的wasm binary?
(论文阅读)Go or No Go-Differential Fuzzing of Native and C Libraries
Go or No Go: Differential Fuzzing of Native and C Libraries
时间:2023.5
作者:Alessandro Sorniotti(IBM)、Michael Weissbacher、Anil Kurmus
会议:S&P‘2023
Abstract 十多年来,Go 已经成为当今最流行的编程语言之一。Go 是一种静态类型的编译语言,通过强类型、自动插入的边界检查和标记-清扫垃圾收集器,实现了空间和时间上的内存安全性。Go 开发人员可以即时使用大量的本地库,这些库可以作为运行时的一部分提供,也可以从社区代码中导入;或者,Go 开发人员可以直接链接到 C/C++ 库,这些库可以通过cgo功能从GO源码中调用。做出支持以上功能的这一决定的原因包括稳定性、性能和可用性。因此,开发人员可以在 Go 本地库或非本地代码之间做出选择。然而,如今人们对如何在这一决策中考虑安全问题还知之甚少。
(论文阅读)Security Risks of Porting C Programs to WebAssembly
(论文阅读)Security Risks of Porting C Programs to WebAssembly
时间: 2022
作者:Quentin Stiévenart、Coen De Roover、Mohammad Ghafari
会议:Proceedings of the 37th ACM/SIGAPP Symposium on Applied Computing
Abstract WebAssembly是一种用于跨平台应用程序的编译目标,目前正被越来越多地使用。在本文中,我们研究了能否将 C 程序不需要大量修改直接编译到 WebAssembly 中,如果不能,移植会对其安全性产生什么影响。我们将表现出常见漏洞的17802个程序编译成64位的x86和WebAssembly二进制文件,并观察到在这些平台上执行4911个二进制文件会产生不同的结果。
通过人工检查,我们找出了造成这种差异的三类根本原因:
使用了不同的标准库实现;
WebAssembly 缺乏安全措施;
执行环境的语义不同。
我们描述了我们的观察结果,并讨论了从安全角度来看至关重要、最需要开发人员关注的问题。我们的结论是,将现有的 C 程序编译成 WebAssembly 进行跨平台发布可能需要对源代码进行调整;否则,WebAssembly 应用程序的安全性可能会受到威胁。
(技术积累)AFL++ Instrumention for WAVM
(技术积累)AFL++ Instrumention for WAVM 利用AFL++自带的compiler warpper对WAVM插桩,一些Bug的记录分析。
(论文复现)CompDiff(一) 实验复现
(论文复现)Finding Unstable Code via Compiler-Driven Differential Testing 对论文《Finding Unstable Code via Compiler-Driven Differential Testing》的过程复现+代码分析。
(论文阅读)★Finding Unstable Code via Compiler-Driven Differential Testing
Finding Unstable Code via Compiler-Driven Differential Testing
时间:2023
作者:Shaohua Li、Zhendong Su(苏黎世联邦理工)
会议:ASPLOS(CCF-A)
开源:shao-hua-li/compdiff (github.com)
Abstract 不稳定的代码是指由于程序中存在未定义行为(UB),导致运行时语义不一致或不稳定的代码。编译器通过假设未定义行为永远不会发生来利用UB,从而生成高效但潜在语义不一致的二进制文件。实践者们在设计动态工具(例如sanitizers)来处理常见的UB问题时已付出了大量研究和工程努力。然而,目前的技术仍面临一个重大挑战,即如何检测那些超出当前技术范围的UB问题。
在本文中,我们介绍了一种名为Compiler-driven differential testing(CompDiff)的简单而有效的方法,用于发现C/C++程序中的不稳定代码。CompDiff利用了一个事实,即当编译不稳定代码时,不同的编译器实现可能会生成语义上不一致的二进制文件。我们的主要方法是检查相同输入上不同二进制文件的输出。输出的差异可能表明存在不稳定的代码。为了在实际程序中检测不稳定代码,我们还将CompDiff集成到AFL++中,这是最常用且积极维护的通用模糊测试工具。
尽管CompDiff的方法简单,但实践中非常有效:在Juliet基准程序上,相比于sanitizers,CompDiff独特地检测到1,409个错误;在23个流行的开源C/C++项目中,CompDiff-AFL++发现了78个新错误,其中52个已经被开发人员修复,而36个无法通过sanitizers检测出来。我们的评估还揭示了一个事实,即CompDiff的设计并不是为了取代当前的UB检测工具,而是为它们提供补充。
(论文阅读)UTOPIA-Automatic Generation of Fuzz Driver using Unit Tests
UTOPIA: Automatic Generation of Fuzz Driver using Unit Tests
时间:2022
作者:Bokdeuk Jeong、Joonun Jang(Samsung Research)、Taesoo Kim(佐治亚理工)
会议:S&P’2023
开源:https://github.com/Samsung/UTopia
Abstract Fuzzing可以说是检测软件安全漏洞的最实用方法,但采用这种方法需要付出不小的努力。要想取得成效,高质量的fuzz driver程序应首先应当包含适当的 API 序列,以便详尽地探索程序状态。为减轻这一负担,现有解决方案试图通过从用户代码(即 API 的实际使用)中推断出有效的 API 序列,或直接从样本执行中提取 API 序列来生成fuzz driver程序。遗憾的是,所有现有方法都存在一个共同问题:观察到的 API 序列(无论是静态推断还是动态监控)都与自定义应用程序逻辑混杂在一起。然而,我们观察到,单元测试是由应用程序接口的实际设计者精心制作的,以验证其正确使用,而且重要的是,在开发过程中编写单元测试是一种常见做法(例如,超过 70% 的流行 GitHub 项目)。
在本文中,我们提出了一种开源工具和分析算法—UTOPIA,它可以从现有的单元测试中自动合成有效的fuzz driver程序,几乎不需要人工参与。为了证明其有效性,我们将 UTOPIA 应用于 55 个开源项目库,包括 Tizen 和 Node.js,并从 8K 个合格的单元测试中自动生成了 5K 个fuzz driver程序。此外,我们在每个内核上执行了约 500 万小时生成的fuzzer,发现了 123 个错误。更重要的是,2.4K 个生成的fuzz driver程序被Tizen项目的持续集成流程采用,这表明了合成fuzz driver程序的质量。为了让研究人员和从业人员更广泛地采用,我们公开并维护了所提出的工具和结果。
(技术积累)How does AFL++ run a program?
(技术积累)How does AFL++ run a program?
前提:使用AFL++对开源程序fuzzing。
当对目标程序插桩完毕后,在一次运行中AFL++:
如何准备运行的环境?
如何获得程序的输入\输出?
如何判断程序是否崩溃/对应sanitizer是否触发?
如何获取这一次的代码覆盖率并记录结果?