Apache Log4j 漏洞的影響規(guī)模

來自 Google Open Source Insights Team 的安全研究人員通過調(diào)查?Maven Central 中所有軟件包的所有版本，以更好地了解最近曝出的 Log4j 漏洞對整個 JVM 語言生態(tài)系統(tǒng)的影響，同時還跟蹤了正在進(jìn)行的緩解受影響軟件包的工作。

研究人員發(fā)現(xiàn)，截至 2021 年 12 月 16 日，來自 Maven Central 的 35,863 個可用軟件包依賴于存在漏洞的 log4j 代碼。這意味著 Maven Central 上超過 8% 的軟件包至少有一個版本受漏洞影響（此數(shù)字不包括所有 Java 軟件包，例如直接分發(fā)的二進(jìn)制文件）

就生態(tài)系統(tǒng)影響而言，8% 是相當(dāng)巨大的數(shù)字。因為對 Maven Central 生態(tài)的平均影響數(shù)值為 2%，中位數(shù)則低于 0.1%。

如記錄漏洞的 CVE 所述，大多數(shù)受影響的軟件包來自間接依賴項（即自身依賴項的依賴項），也就是說它們沒有將 log4j 明確定義為依賴項，而是作為傳遞依賴項被引入進(jìn)來。

這正是 JVM 生態(tài)整體上修復(fù)此漏洞異常困難的原因。安全研究人員稱，在撰寫文章時，只修復(fù)了近五千個受影響的軟件包，還有 30000 多個軟件包會受到漏洞的影響。

簡單來說就是，漏洞在依賴關(guān)系鏈中嵌套得越深，修復(fù)漏洞所需的步驟就越多。下圖顯示了受影響的 log4j 包（核心或 api）首次出現(xiàn)在依賴圖中的深度的直方圖。對于超過 80% 的軟件包，該漏洞的深度超過一級，其中大多數(shù)受影響的級別下降了 5 個級別（有些甚至下降了 9 個級別）。這些包將需要在依賴樹的所有部分進(jìn)行修復(fù)，而且首先從最深處的依賴關(guān)系開始。

修復(fù)漏洞的另一個困難之處由解析算法 (resolution algorithm) 和需求規(guī)范約定中生態(tài)系統(tǒng)層級的選擇引起。

在 Java 生態(tài)中，開發(fā)者通常的做法是指定軟件版本方面的“軟”要求——假設(shè)沒有其它版本的相同包出現(xiàn)在依賴關(guān)系圖中，解析算法會使用指定的明確版本。對于此類修復(fù)，通常需要維護(hù)者采取更加明確的行動，以將依賴需求更新為修補后的版本。這種做法與其它生態(tài)形成了鮮明的對比，例如在 npm 軟件包中，開發(fā)者通常會為依賴項指定開放范圍。開放范圍允許解析算法選擇滿足依賴性要求的最近發(fā)布的版本，從而引入新的修復(fù)。

最后，對于整個生態(tài)需要耗費多少時間來完成漏洞修復(fù)，目前也很難評估。在查看了所有公開披露的受影響 Maven 軟件包中，安全人員發(fā)現(xiàn)只有不到一半（48%）得到了修復(fù)。

文章轉(zhuǎn)載：OSC開源社區(qū)
（版權(quán)歸原作者所有，侵刪）

點擊下方“閱讀原文”查看更多