Fuzz 入门能做到和做不到的
跑满 24 小时再看覆盖率曲线,前两个小时的结论通常不准,排期按天算而不是按小时
任何分析手段都有边界,承认边界才能给出可靠的结论。
先说结论
能说清边界,结论才可信。
- 可观察:运行时数据
- 可推:结构与布局
- 不可得:原始源码
- 结论要带置信度
- 成本:影响面:决定漏洞发现上限;接入约 3 人日
能确定的
进程内 fuzz 每秒能跑上万次,fork 模式通常只有一千次左右,这个差距决定单位时间产出,能进程内就别 fork。
凡是运行时会用到的数据,最终都能观察到。
只能推测的
种子语料的质量比变异策略更影响前期覆盖率,喂错种子等于白跑,语料要覆盖格式各分支,也要按格式分层。
| 对象 | 可还原程度 | 原因 |
|---|---|---|
| 控制流 | 高 | 运行路径可观察 |
| 数据结构 | 中 | 布局可推,命名靠猜 |
| 业务意图 | 低 | 取决于命名与注释 |
| 原始源码 | 不可能 | 编译有损 |
几个具体限制
下面这些是相对确定的细节:
- 崩溃必须去重,同一个空指针解引用能产出几千条重复样本

怎么给出可靠结论
结论要带置信度:确定、较可能、推测。Fuzz 的产出不是崩溃数量,是覆盖率还能不能继续往上走。
还有几处容易忽略的
这些细节不影响入门,但影响你判断的准确度。
- 没有覆盖反馈的随机测试,命中深层路径的概率低到可以忽略,除非解析逻辑只有两三层分支,这类目标本来也少
- sanitizer 能把静默的越界读写变成可见崩溃,是 fuzz 的放大器
- 跑满 24 小时再看覆盖率曲线,前两个小时的结论通常不准,排期按天算而不是按小时
- 只跑一小时就下结论说没有漏洞,样本量远远不够
- 用生产数据当种子,把敏感信息带进语料库
- 不做去重,报告里几千条崩溃全是同一个
承认做不到,是专业的一部分。
评论 (3)
审计检查点可以直接做成 checklist。
日志留存时间那条被我们领导采纳了。
终于有人讲清楚「为什么」而不是只给命令。
发表评论