谷歌開源洞察團隊詳解Apache Log4j漏洞造成的廣泛影響
上週五,谷歌開源洞察團隊在官方安全博客上發表了一篇文章,詳細介紹了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%)得到了修復。 剩下的工作,仍需全球開源維護者、資訊安全團隊和廣大使用者付出巨大的努力。