[[441367]]

上周五，谷歌開源洞察團隊在官方安全博客上發表了一篇文章，詳細介紹了 Apache Log4j 漏洞對行業造成的廣泛影響。James Wetter 和 Nicky Ringland 指出，超過 35000 個 Java 包、占總數 8% 以上的 Maven 中央存儲庫，尤其讓我們對其留下的隱患感到擔憂。

(來自：Google Security Blog)

據悉，這些漏洞允許攻擊者利用 Log4j 日志庫已被廣為人知的不安全 JNDI 查找功能來執行遠程代碼。糟糕的是，這項功能在許多版本中都被默認啟用。

自 12 月 9 日披露以來，Log4j 漏洞因其嚴重性和廣泛影響，而引起了信息安全生態系統的高度關注。畢竟作為一款流行的日志工具，它已被數以萬計的軟件包(Java 里的 Artifacts)和項目所使用。

由于用戶對 Log4j 的傳遞依賴項缺乏足夠的遠見，這不僅使得我們很難確定零日漏洞的影響范圍、相關修復工作也變得相當困難。

期間，Google 開源洞察團隊調查了 Maven 中央存儲庫中的 Java 工件的所有版本，最終將范圍縮小到了基于 JVM 語言的開源生態系統，同時密切追蹤事態的發展。

截至 2021 年 12 月 16 日，該團隊發現來自 Maven Central 的 35863 個可用 Java 工件，有依賴于受影響的 log4j 代碼。

這意味著，僅 Maven Central 平臺上超過 8% 的軟件包，都至少有一個版本受此漏洞的影響。

若放眼整個生態系統，漏洞威力更是不容小覷(Maven Central 的平均影響為 2% / 中位數低于 0.1%)。

直接受影響的依賴項，約占這部分工件中的 7000 個，意味著它們的任何版本都被 Log4j-core 或 Log4j-api 所波及(完整列表可見 CVE 漏洞披露公告)。

此外大多數受影響的工件，都來自間接的依賴項，即它們是作為傳遞依賴項而被牽扯進來的。

至于當前開源 JVM 生態系統的修復進展，若工件中至少有一個版本受到了影響，且發布了一個不受漏洞波及的更穩定版本，谷歌開源洞察團隊就將之視作已修復。

比如受 Log4j 漏洞影響的工件已更新到 2.16.0、或完全剔除了對 Log4j 的依賴。慶幸的是，Log4j 維護者和更廣泛的開源社區對此問題的響應是相當迅速的，并且付出了切實的巨大努力。

截止博客發表時，團隊統計到了將近 5000 個已被修復的項目。至于剩余的那 30000 個工件，其中許多依賴于另一個工件。在傳遞依賴被修復前，暫時只有一刀切來阻止。

對于 Java 生態系統來說，修復難度主要體現在工件的互相連接。首先，依賴鏈越深，漏洞修復所需的步驟就越繁雜(超過 80% 軟件包的深度都超過了一級)。

其次，依賴算法和需求規范中的生態系統級選擇約定，也為事件埋下了較大的伏筆。在 Java 生態系統中，開發者的通常做法是指定軟件版本方面的“軟”要求(假設沒有其它版本的相同包出現在依賴關系圖中)。

此類修復通常需要維護人員采取更加明確的行動，以將依賴需求更新為修補后的版本。這種做法與其它生態系統形成了鮮明的對比，例如在 npm 軟件包上，開發者通常會為依賴項指定敞開的范圍。

最后，對于整個生態系統需要耗費多少時間來完成漏洞修復，目前也很難評估。在查看了所有公開披露的影響 Maven 包的關鍵建議中，我們發現只有不到一半(48%)得到了修復。

不過在 Log4j 方面，事情還算是相當積極的。不到一周后，就有 4620 個受影響的工件(約 13%)得到了修復。剩下的工作，仍需全球開源維護者、信息安全團隊和廣大用戶付出巨大的努力。