# Fuzzing: Challenges and Reflections

**URL:** <https://forum.90sec.com/t/topic/1299>\
**Category:** 学术研究\
**Created:** [2020 年9 月 22 日 03:01 UTC](https://forum.90sec.com/t/topic/1299 "2020-09-22T03:01:15Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![maplgebra](https://forum.90sec.com/user_avatar/forum.90sec.com/maplgebra/32/1628_2.png) [@maplgebra](https://forum.90sec.com/u/maplgebra)\
发布日期： [2020 年9 月 22 日 03:01 UTC](https://forum.90sec.com/t/topic/1299/1 "2020-09-22T03:01:15Z")

</div>

# Fuzzing: Challenges and Reflections

### 0x00 自动化

1. **需要更多的fuzz工具，针对不同类型的对象** ，the questions：

2. **如何去发现更多类型的bug？**

3. **如何去发现更深层次的bug？** (这样的bugs通常满足复杂的触发条件)，下面是一些有趣的解决方案。

4. **需要更多的对bug的认知经验**

5. **fuzzer从来都不是一个黑盒子！**

6. **如何增强fuzzer的易用性？**

### 0x01 Fuzzing 论

> ​ It is important for any discipline to stand on a firm scientific foundation

有许多前沿的fuzzing技术，但是如何证明某种方法就一定比其他的方法要好呢？这些方法的局限性是什么？我们需要去解释这些方法所产生的结果，并能从结果中做出推断。为了实现这些，我们迫切需要有一个完整针对fuzzing的理论模型。

1. **当fuzzing过程失败的时候，如何去评估剩余的威胁等级？** （失败可以理解为fuzzing结束没有得到相关的bugs结果）

2. **黑盒fuzzing，灰盒fuzzing，白盒fuzzing它们的理论限制是什么呢？**

### 0x02 评估和基准测试

当一个新的fuzzing技术横空出世的时候，我们需要用完整的方法去评估它。一般来说，我们常常关注它是否能在合理的时间中找到更多有趣的bugs （the better fuzzer）。 那么问题就来了，“合理的时间”，“有趣的bugs”，如何去用更本质方法的描述呢？如何防止过度拟合呢？ 合适的基线对照组应该是什么呢？ 如何比较它们的effectiveness和efficency

1. 如何评估一些特殊的fuzzers？

2. 如何防止benchmark过度拟合？

3. 人造的bugs是否说明问题？

4. fuzzer 发现的real world bugs是否之前已经被发现了？是否有代表性？

5. 覆盖率是否真的是一个用于测量fuzzer effectiveness好的度量？

6. 什么是合理的时间预算？

7. How do we evaluate techniques instead of implementations？

### 自己的观点

最大的感触就是“Human in the loop”，我把它翻译成了Fuzzing从来都不是一个黑盒子，这一点我自己深有感触，在做实际做东西当产品用的时候，却偏偏让你做成一个黑盒子，这一类的安全产品实际上并不是给完全不会安全的人用的，这一点要特别明确。但是让安全产品快速的让普通的程序员，就马上使用，在未来依然是一个很大的挑战。关于evaluate的东西我记录的很少，因为我总觉得没有一个规范的东西在那里，也许小领域也就这样，没有完整而坚实的理论基础，Fuzzing未来的路真的还有很远要走。