[[441367]]

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

(來自：Google Security Blog)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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