Fuzz 入门能做到和做不到的

逆向工程 · 2 分钟阅读· 327 次阅读

跑满 24 小时再看覆盖率曲线,前两个小时的结论通常不准,排期按天算而不是按小时

任何分析手段都有边界,承认边界才能给出可靠的结论。

先说结论

能说清边界,结论才可信。

  • 可观察:运行时数据
  • 可推:结构与布局
  • 不可得:原始源码
  • 结论要带置信度
  • 成本:影响面:决定漏洞发现上限;接入约 3 人日

能确定的

进程内 fuzz 每秒能跑上万次,fork 模式通常只有一千次左右,这个差距决定单位时间产出,能进程内就别 fork。

凡是运行时会用到的数据,最终都能观察到。

只能推测的

种子语料的质量比变异策略更影响前期覆盖率,喂错种子等于白跑,语料要覆盖格式各分支,也要按格式分层。

对象 可还原程度 原因
控制流 高 运行路径可观察
数据结构 中 布局可推,命名靠猜
业务意图 低 取决于命名与注释
原始源码 不可能 编译有损

几个具体限制

下面这些是相对确定的细节:

  • 崩溃必须去重,同一个空指针解引用能产出几千条重复样本

Fuzz 入门能做到和做不到的

怎么给出可靠结论

结论要带置信度:确定、较可能、推测。Fuzz 的产出不是崩溃数量,是覆盖率还能不能继续往上走。

还有几处容易忽略的

这些细节不影响入门,但影响你判断的准确度。

  • 没有覆盖反馈的随机测试,命中深层路径的概率低到可以忽略,除非解析逻辑只有两三层分支,这类目标本来也少
  • sanitizer 能把静默的越界读写变成可见崩溃,是 fuzz 的放大器
  • 跑满 24 小时再看覆盖率曲线,前两个小时的结论通常不准,排期按天算而不是按小时
  • 只跑一小时就下结论说没有漏洞,样本量远远不够
  • 用生产数据当种子,把敏感信息带进语料库
  • 不做去重,报告里几千条崩溃全是同一个

承认做不到,是专业的一部分。

评论 (3)

阿
阿哲

审计检查点可以直接做成 checklist。

K
Kai

日志留存时间那条被我们领导采纳了。

路
路人甲

终于有人讲清楚「为什么」而不是只给命令。

发表评论

验证码

提交后需站长审核,通过后才会显示。