Fuzz

在《Fuzzing(模糊测试)的前世今生(上)》和《Fuzzing(模糊测试)的前世今生(中)》我们讲解了模糊测试技术的由来、技术原理和底层算法,本篇我们为大家简述一下模糊测试的实践应用,让大家对它有更深的了解。
在上一篇《Fuzzing(模糊测试)的前世今生(上)》中,我们讲解了模糊测试技术的由来,本篇我们重点为大家阐述一下模糊测试的技术原理和底层算法。
之前我们在《Fuzzing(模糊测试)技术,你真的了解吗?》一文中提及了模糊测试概念的兴起,描述比较简单。
本文的作者设计了一个工具GFuzz,用来针对channel-related concurrency bug进行挖掘。首先需要定位可能引入bug的并发channel,并对程序完成改写与编译,使之支持channel中信息的乱序到达。
与 Syzkaller 类似,Healer 使用 Syzlang 描述所提供的 syscall 信息来生成确认参数结构约束和部分语义约束的系统调用序列,并通过不断执行生成的调用序列来发现内核错误,导致内核崩溃。
现有 fuzz 大多以代码覆盖率为引导指标。以AFL为例,它使用映射至 hashmap 中的基于 edge 的覆盖率信息来引导测试。这种覆盖率信息不太准确,因为只统计至 edge 层面,同时还会产生覆盖 hash 冲突,丢失覆盖率信息,给模糊测试带来一些不良限制。
火狐内部的进程间通信(IPC)层是火狐多进程安全架构的基石。
相关源代码以及构建方式已开源至 github 上。重申一下,该 fuzz 目前处于实验性版本,可能有亿点点不太稳定(笑)。
Directed fuzzing 可以翻译为定向模糊测试,导向型模糊测试,是灰盒模糊测试中的一种。
本文提及的IPC fuzzer方法通过程序拆解和分析应用程序的字节码来实现fuzz功能,而且该fuzzer支持输入生成分析和输出后结果分析,这些结果可以使我们了解崩溃原因详情。