【51CTO.com快譯】12月9日，Apache 基金會針對一個名為 Log4Shell 的關鍵零日漏洞發布了緊急更新，這個在Log4j（一個用于各種Java應用的開源日志框架）中發現的漏洞被認定為CVE-2021-44228，允許攻擊者在任何使用Log4j庫寫出日志信息的系統上執行任意代碼。它立即被評為CVSS等級中的最高嚴重程度10級。

?[[441636]]??

正如 Cloudflare 首席技術官John Graham-Cumming所說："這可能是自 Heartbleed 和 ShellShock 以來互聯網上最嚴重的漏洞之一。"

加固第一道防線

在漏洞被公布之后，開發人員和維護人員立即著手給他們的 Java 應用程序打上盡可能多的補丁。由16名無報酬志愿者組成的 Apache 軟件基金會日志服務團隊也第一時間加固 Log4j 本身。

北京時間11月24日，Apache日志服務項目管理委員會（PMC）收到了一封爆炸性的郵件。阿里云安全團隊報告了Log4j2 軟件中存在一個零日安全漏洞。

軟件工程師、PMC 成員 Gary Gregory 表示：“這將是一個重大的問題。”

該團隊立刻開始修補這個問題，但這個漏洞在12月9日被公之于眾后，他們的時間安排迅速加快了。

Gary和其他維護者放下手上的工作，加班加點來修復這個漏洞問題。在發布 2.15 版更新之前，他們很快決定這個更新“不夠好”，隨后，他們在格林尼治標準時間12月13日晚上10點28分發布了2.16版本。

"我知道他們都有家庭和他們必須做的事情。但他們把一切都放在一邊，整個周末都在修復這個漏洞。"前 Log4j 開發者 Christian Grobmeier 告訴彭博社。

到周末的這個時候，PMC的活躍成員已經轉向通過私人Slack頻道進行溝通，在那里他們繼續解決這個問題，并共同努力為操作舊版本 Java 的用戶提供更新。他們很快就發布了 2.12.2 版本來解決 Java7 用戶的問題。Java6 的修復被證明更棘手，但這是他們的下一個待辦事項。

“總的來說，我認為盡管這種漏洞會帶來可怕的后果，但事情進展得如經驗豐富的開發人員所預料的那樣，” Gary 說。“我們收到通知，迅速提供了補丁并在該版本上進行迭代。

構建熱補丁和緊急指導

另一個在周末迅速行動的小組是亞馬遜 Corretto 團隊。Corretto 是 Open Java Development Kit (OpenJDK) 的一個發行版，這使 Corretto 團隊處于Log4Shell問題的第一線。

在首席軟件工程師Volker Simonis的帶領下，Corretto團隊迅速建立并開源了一個熱補丁，供任何無法立即更新的組織使用。

正如GitHub頁面上所描述的那樣：

• 這是一個將 Java 代理注入運行中的 JVM 進程的工具。該代理將嘗試修補所有加載的 org.apache.logging.log4j.core.lookup.JndiLookup實例的lookup()方法，無條件地返回字符串 "Patched JndiLookup::lookup()"。
• 該熱補丁旨在解決Log4j中的 CVE-2021-44228 遠程代碼執行漏洞，無需重啟Java進程。據了解，動態和靜態代理在Linux的JDK 8和JDK 11上運行，而在JDK 17上只有靜態代理在工作。

"非常感謝亞馬遜Corretto團隊花了幾天、幾夜和周末的時間來編寫、加固和運行這段代碼，"AWS CISO Steve Schmidt在一篇博文中寫道。AWS還發布了一份針對受影響產品的特定服務安全更新的詳盡清單。

在其他地方，由 Java 首席工程組經理 Martijn Verburg 領導的 Microsoft Java 團隊成員幫助評估了該補丁，并為客戶發布了更一般的保護自己的建議，包括幾個推薦的解決方法，直到可以應用完整的安全更新.

谷歌云以更新其Cloud Armor安全產品作為回應，該產品于 12 月 11 日發布了一項緊急 Web 應用程序防火墻 (WAF) 規則，以幫助檢測和阻止 CVE-2021-44228 的企圖利用。

“為了幫助我們的客戶解決 Log4j 漏洞，我們引入了一個名為“cve-canary”的新預配置 WAF 規則，它可以幫助檢測和阻止 CVE-2021-44228 的漏洞利用嘗試，”Cloud Armor的產品經理Emil Kiner和谷歌的網絡專家經理 Dave Reisfeld 在一篇博文中寫道。

你可以做什么？

當這些內部開發人員匆匆忙忙為客戶保護他們的軟件時，許多最終用戶和企業開發人員正爭先恐后地評估他們的漏洞并保護他們自己的Java應用程序。

首先要做的是檢測Log4j是否存在于你的應用程序中。同樣重要的是要注意，不是所有的應用程序都會受到這個漏洞的攻擊。任何使用高于6u212、7u202、8u192或11.0.2的Java版本的人都應該是安全的，因為這些版本中增加了對JNDI（Java命名和目錄接口）遠程類加載的保護。

同樣，高于2.10版本的 Log4j 用戶應該通過設置系統屬性formatMsgNoLookups為true，設置JVM 參數-Dlog4j2.formatMsgNoLookups=true，或從classpath中刪除JndiLookup類來緩解這一問題。

由于Log4j漏洞不僅影響Java應用程序，而且還影響使用該庫的任何服務，因此Log4Shell的攻擊面可能非常大。

正如Lucian Constantin為CSO寫的那樣："社區仍在努力評估攻擊面，但由于依賴關系的復雜生態系統，它可能是巨大的。一些受影響的組件是非常流行的，被數以百萬計的企業應用和服務所使用"。

就其本身而言，Apache Logging Services團隊將 "繼續評估可能存在潛在安全風險的Log4j功能，并將進行必要的修改以刪除這些功能。Apache Logging Services團隊的成員Ralph Goers告訴InfoWorld，"雖然我們將盡一切努力保持向后兼容，但這可能意味著我們必須禁用他們可能正在使用的功能。

即使無數的開發者在周末不知疲倦地修補Log4j的漏洞，也會有很多人反應較慢。因此，Log4Shell的影響可能是長期和廣泛的。

正如安全分析師Tony Robinson在推特上所說。"雖然那些好的公司通過打補丁迅速解決了問題，但還是會有很多地方不會打補丁，或者在一段時間內無法打補丁。"

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】