| layout |
|---|
default |
这篇黑客大会的文章观点和我最开始接触内核利用时的想法相似，只不过当时碍于知识面有限没能实现这种想法。
文章目的是为了解决Linux内核OOB漏洞的利用难题，其实对UAF的利用也有一定的帮助。OOB利用的基本步骤是：
- 定位Vul对象
- allocate大小相同的对象(可控，并紧邻Vul对象)
- 触发Vul对象
难题是如何布置Vic对象，使其紧邻Vul对象或相隔规定的距离(因为Vul对象可能好用的OOB指针比较远)，当然文章还介绍了如何控制Vic对象的内容，以及如何选取合适大小的Vic对象，但这都不是最困难的问题，甚至有一类内核对象可以生成任意大小的可控内核对象，如msg对象。
- 通过静态分析和回归测试集测试，生成Linux内核对象数据库
- 处理slub分布情况
- Target is Unoccupied: 这类问题比较简单，在allocate Vic对象前，先allocate同类型对象占据与Vul间隔的距离即可，然后再生成Vic对象覆盖Target目标即可。
- Target is Occupied: 这类问题比较困难，也是经常遇到的问题，在allocate Vic对象时，由于其他进程的干扰，可能有另外一个相同大小的核心对象已经先入为主占据了Target对象。文章给出了一种解决方案，即调整slub链表的顺序，比如1->2->3调整为1->3->2，那么Vul | Dummy | Vic的空间分布就会调整为Vul | Vic | Dummy的顺序，达到可控的目的。
具体方案：
- 申请可控的x个对象(x为slub链表的长度)
- 按制定顺序释放这x个对象，例如释放顺序为2-3-1，那么slub链表的freelist的顺序就变成了1->3->2
- 申请Vul对象和Vic对象，由于Vul对象的副作用是生成Dummy对象，因此slub链表空间分布就变成了Vul | Dummy | Vic的分布。
文章的思路可以借鉴，只是内核的slub链表并没有那么容易控制，往往会呈现出"CPU-partial slub list-LRU list"三层带有优先级的分配层级，可能会出现预计之外的情形；另外，实际利用过程中副作用很可能是随机的，即不能确定Vul对象与Vic对象之间存在多少个非可控对象，这还需要进一步研究。