聊聊“0-day In-the-Wild Exploitation…so far”

看起来现在也就只能蹭蹭p0的热度及流量了，昨天p0又发了篇blog 还是那个女人 还是说0day在野的话题 

https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html

这篇文章其实算是 2022年6月在FIRST研究主题 ppt：

https://github.com/maddiestone/ConPresentations/blob/master/FIRST2022.2022_0days_so_far.pdf

这个主题还是跟前面那篇关于CVE-2022-2260的文章差不多，主要探讨漏洞在修复的时候只考虑POC执行的路径进行修复，而且修复点在路径“靠前”的位置或者说路径覆盖不全，并没有成根本上解决问题。漏洞挖掘着只要去找到新的漏洞触发路径就能重新复活漏洞，当然这种在我们漏洞挖掘套路里算是非常常见的，p0的ppt里举的几个列子还是非常有代表性的，最后的结论也没啥问题，只是我可能觉得修复者的安全理解很可能达不到跟顶级安全研究者一样的水平，并且之前我也提到过对于很复杂庞大的项目要做到这个要求难度是非常大的，更何况很有可能你的补丁可能带入新的漏洞的可能？！

我比较有不同看法的是p0那个列表，有点凑数的嫌疑！

比如其中把 CVE-2022-30190 (“Follina”) 当成是 CVE-2021-40444 (2021 itw) 修复后的变体（，还有 Confluence 的 CVE-2022-26134 说是 CVE-2021-26084 修复后的变体 ，是比较牵强的，当然可以理解啊这种漏洞p0很可能不太乐意去分析相关啊（阴阳怪气～～）

关于CVE-2022-30190 这个具体可以参考我之前的文章《聊下最近的CVE-2022-30190》，如果p0认为用word调用URL触发IE攻击面算是通用的核心的，先不说这个属于word的“正常功能”，即使微软在这个点做了修复也没有做到漏洞最终修复，很可能还存在其他攻击路径去处罚，只是说这个点对于在野0day检测捕获是ok的这个点在我之前的文章也提到了。

对于防御的角度，在10余年前的ppt里《我的安全世界观》

https://www.slideshare.net/dleyanlin/superhei

提到的“最短路径”防御思想，那个时候我基本上是按“二次漏洞”模型提炼出来的观点，顺带提一句“二次漏洞”的模型跟内存型“UAF”漏洞模型有“异曲同工”的地方，对于漏洞挖掘同样在10余年前的ppt《WEB代码审计与渗透测试》

https://paper.seebug.org/papers/old_sebug_paper/other/

里总结过：

比如相识性漏洞模型，比如深入理解功能与漏洞等 因为当时做的基本都是开源的web代码审计，虽然可能有人认为跟p0里面漏洞触发“路径”具象的不同，但是最终表达的场景意思是基本一样的。我ppt里提到的功能与漏洞问题有一个很典型的漏洞，当年某著名的程序，在实现某个功能的时候（“发文章”跟“编辑文章”），官方在某个版本修复了一个注入漏洞是在“发表文章”的时候触发，于是我按这个套路看了下“编辑文章”果然存在同样的问题而且还没有修复！看代码发现，这个程序开发“发文章”跟“编辑文章”是分开的代码实现，只是实现代码几分一样，理论上算是2个不同漏洞了，如果套用上面提到的包括p0的文章里的模型了不能算是修复路径的问题，因为在“发表文章”那个点是彻底修复了的，所以我提到的这个例子可能比p0文章提到的场景更加复杂一点了，再比如对开发者的理解：同一个程序员写的代码必然有相同的漏洞 ... 等等

后话：

其实有很多人不太喜欢我老提以前的东西，说像个老年痴呆一样的喋喋不休！其实对这个问题我是不太认同的：1、确实不过时，有的理念现在还有很好的应用空间及场景，因为每当我有一些“新”思考的时候，其实最后还是回到了n年前就总结过的东西。2、当然我也不是一直炒冷话，我也一直在做热饭热菜，对吧！：）