捉虫日记漏洞总结
前言
最近阅读了捉虫日记这本少有的讲述漏洞挖掘方法的书籍，本书虽然只有7个漏洞，但是对每个漏洞到底是如何发现的做了很详细的说明，还原了漏洞挖掘的思维过程，笔者认为这是本书最有价值的一块内容，现在大部分的文章都是讲述了漏洞原理但是对于漏洞是如何发现的内容涉及很少。漏洞的发现过程是比较琐碎的，甚至难以回忆，很容易忘记当时的发现的思路历程，所以比较难成文，笔者也将努力将原书中我比较喜欢的几个漏洞的ROOT CAUSE和如何找到做一些简单的总结。
0x00 ESCAPE FROM WWW ZONE漏洞
ROOT CAUSE
由于有错误条件是两个方式共同表示的，返回值和一个参数值，当出现错误条件的时候，只设置了其中一个条件（返回值）忘记设置了参数，由于对同一个错误状态的两种表达方式不同步，最终导致这个oob如何发现这个漏洞
- 观察错误条件是否是两个因素或者多个因素决定的，对于这种编程范式就可以好好审计
- 构造好fuzz条件，fuzz 输入payload
0x01 NULL POINTER FTW漏洞
ROOT CAUSE
由于对长度信息的处理不恰当，将一个unsigned 类型直接赋值给 有符号的变量，对这个长度信息所做的任何判断大小比较都会存在风险。如何发现这漏洞
对于TLV格式的数据，定位抽取长度的变量，观察这个变量是否赋给了有符号的变量，不需要对所有的类型转换进行审计，只需要对这种标识长度的变量的类型转换进行审计就行。这种有符号的比较大小本身就是容易出问题，有符号的比较就要考虑到小于0的情况漏洞利用
造成的是NULL pointer derefernce，但是这个并不是制造成了dos，还造成了控制ip，由于这个空指针应用的偏移是可控的，所以可以落到got表中，对got表的修改，即可以在紧接着的call 目标got表函数时造成劫持
0x02 ONE KERNEL TO RULE THEM ALL 漏洞
- ROOT CAUSE
memcpy函数的第一个参数是任意可变的，即使n是固定值，直接实现了write what where - 如何发现这个漏洞
- 作者还是通过跟踪数据流向的方法在静态的审计函数的处理流程，重点关注了与长度相关的处理逻辑，但是这个漏洞不需要dst与n的不同步即可触发，或者可以理解为是不同步的一种特殊情况，由于dst是任意的，所以永远与n不同步。
- 除了仔细审计与长度相关的代码，还需要注意的是当涉及到与memcpy这种dst，src，和copy数目相关的函数的时候，一定要重点关注dst和num这两个值，要关注dst的来源是什么，是否和num同步，是否可能造成溢出，像这个漏洞是否dst是直接由用户指定的，这都是根据dst的来源而定的
0x03 A BUG OLDER THAN 4.4BSD 漏洞
- ROOT CAUSE
从payload中转化的长度信息，赋值给了有符号数，对有符号的比较，比较绕过，导致越界的访问 - 如何发现这个漏洞
- 在追踪数据流的时候，不仅对数据的长度信息关注，还需要对任何数目相关的字段关注，这些字段的比较大小是容易出错的
- 特别这些数目是有符号数的比较，是非常危险的，一定要注意小于0的情况是否是预期内的
0x04 THE RINGTONE MASSACRE漏洞
- Fuzz方法
变异策略- 通过对一个合法的文件格式进行逐个字节的0xff替换
- 这种变异策略是相对高效的，可以找到一些简单的有关长度的漏洞，而且不需要对格式协议有详细的了解，smb也可以尝试利用同样的方法进行一些测试。
小结
本文主要是对书中几个漏洞的根因进行了提炼，对根因的理解抽象才能够举一反三，所以漏洞原因也尽量精简，笔者也在整理漏洞挖掘方法，但是由于分析的漏洞数量不够多，还不好拿出分享，等到分析足够多的漏洞，到时会以makdown map的形式展示出。
以后也会经常以本篇文章的形式分析一系列漏洞。
版权声明
本文作者为colorlight，转载请注明出处 https://colorlight.github.io