作者：heige@知道創宇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了：http://www.bjnorthway.com/?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 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1926/