简单聊下最近2个有意思的漏洞

CVE-2022-22620
CVE-2022-30136

作者：[email protected]知道创宇404实验室
原文链接：https://mp.weixin.qq.com/s/-fHeQe-00ay7z5JXvvdK1w

CVE-2022-22620

前几天p0的blog更新一篇文章《An Autopsy on a Zombie In-the-Wild 0-day》

针对2022年2月份披露的一个在野漏洞CVE-2022-22620

“考古” 过程，还是比较有意思的～

p0通过一系列webkit代码的commit追踪，这个漏洞最终可以追溯到2013年1月（这个漏洞当时没有分配CVE），当时POC如下

Object.prototype.__defineSetter__("foo",function(){history.replaceState("")});
history.replaceState({foo:1,zzz:Array(1<<22).join("a")});
history.state.length;

随即Webkit修复了该漏洞，由于代码更新中间做了几次漏洞修改，一直到2016年12月的更新导致代码“回滚”重构导致漏洞创新被引入，最后直到2022年1月修复了在野利用并分配了CVE-2022-22620，POC如下：

input = document.body.appendChild(document.createElement("input"));
foo = document.body.appendChild(document.createElement("a"));
foo.id = "foo";
// Go to state1 when history.back is called
// The URL needs to be <currentPage+hash> to trigger loadInSameDocument during the call to back()
// Since the foo's element id="foo", focus will change to that element
history.pushState("state1", "", location + "#foo");
// Current state = state2
history.pushState("state2", "");
setTimeout(() => {
        // Set the focus on the input element.
        // During the call to back() the focus will change to the foo element 
        // and therefore triggering the blur event on the input element
        input.focus(); 
        input.onblur = () => history.replaceState("state3", "");
        setTimeout(() => history.back(), 1000);
}, 1000);

通过p0的文章还提到一些细节，比如使用2013年的poc是没办法直接触发CVE-2022-22620，这个是因为代码经过3年的更新2013年的poc调用路径不能到达漏洞点。

这个漏洞案例告诉我们：

1、考古是非常有意义的！这个不代表CVE-2022-22620就是通过考古挖到的，实际上像webkit这种级别的项目是非常复杂的，及时知道一个漏洞点也要靠肉眼找路径也是非常有挑战性的，在p0的文章里还提到了CodeQL的方法，近几年CodeQL应用成果是有目共睹的，实际上404小伙在19年就开始关注CodeQL了：https://paper.seebug.org/?keyword=CodeQL

并且越来越成熟非常值得关注。当然还有通过多年的关注浏览器安全，有很多专注这个方向研究者通读并且熟读的代码也是有可能的！回到CVE-2022-22620上从POC的代码结构来看，我更加趋向Fuzzing的方式，对于复杂项目找到触发的路径Fuzzing是一个非常简单有效的方法，而且这种因为触发路径不同的同一个漏洞实际上在我们fuzzing过程里还是很常见的（也就是说看起来触发poc不一样，但是触发的漏洞实际上是同一个），有时候我们要获取到更多的不一样的漏洞覆盖，要人工干预避免这种情况，要不然你的算力就反复浪费在同一个漏洞甚至可能是bug上……

顺便提一下在实际漏洞挖掘过程中多种方法是可以结合使用的，比如我在fuzz ie之前就把能收集到历史上各种漏洞甚至包括其他浏览器的漏洞都收集整理过，而且遇到新的漏洞POC都会进行回归测试到fuzz模型上，分析能不能覆盖到！

2、p0的文章里也提到了对于修复者来说应该关注漏洞触发的所有路径，而不仅仅是POC里提到的路径，也就是以前我经常给SRC吐槽的按POC修复漏洞的方式！实际上这个问题是非常难实现的，很多开发者的漏洞理解是不到位的，我以前就专门“考古”找我历史或者其他人的漏洞报告，重新复活漏洞的案例非常多，以至于TSRC当时还接受了我提到的复查评估流程！

3、针对webkit这种复杂的项目，实际上攻击者是可以利用这点的，之前我也提到过很多次的方式：比如去年的“UMN VS Linux kernel”事件这个问题我在2021年的总结里也提到了，当然这种方式是比较直接的，在以往的经验里还存在一些比较隐蔽的，比如我在触发某个漏洞的攻击路径上存在一个bug，也就是说触发这个漏洞必然会触发这个bug，导致流程中断这个时候攻击者提交“主动提交”这个bug的修复补丁，那这种方式就非常不容易被发现了……

4、所以尽管从p0的文章对webkit代码的commit追踪来看2016年12月的代码修改存在主动恶意预谋的可能性不大，但是实际中谁又知道呢？！我们进一步思考可能会发现：漏洞其实并不在“食物链”的“顶端”（这个问题日后有机会再谈）

CVE-2022-30136

这个漏洞是古师傅提交的，在这里提这个漏洞是因为古师傅说这个漏洞存在一个非常有意思的点：

这个漏洞正常普通的请求就可以触发，但是由于NFS内存管理机制估计不会导致crash，而导致很难被注意到！因为我本身对这个漏洞所知甚少，其他点可以自行参考古师傅的内容及回复。

这个漏洞案例告诉我们：

1、Crash不是漏洞触发唯一标准，这个问题我相信很多搞fuzzing的选手有比较深的体会。

2、如果要有意识的预留这种漏洞是不是也有可能呢？！

3、有时候代码写得兼容性太好也不行？：）

Paper 本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1926/