讓全世界大廠都手忙腳亂的代碼漏洞，是怎麼一步步成為噩夢的？_風聞

本文原創於微信公眾號：差評  作者：世超

最近幾天，世超在各家互聯網大廠的程序員朋友們，都快被一個叫 Log4Shell 的史詩級漏洞給折磨瘋了！

這個漏洞源於一個叫 Log4J2 （ Log For Java 2 ）的 Java 開源日誌框架，它在用 Java 敲代碼的碼農羣體裏可以説是無人不知，無人不曉。

它就好像早年間打《 魔獸世界 》一定要裝的大腳插件一樣，屬於真正意義上的**“ 咖啡伴侶 ”**，很少有 Java 程序不用這個組件。

就是這麼一個要命的底層日誌框架，被發現透了一個洞。。。

最先發現漏洞的，是阿里雲安全團隊中，一位叫 Chen Zhaojun 的大佬。

據他的説法，這個漏洞很早就被國外的安全代碼掃描平台掃出來了，圈內的程序員大佬們也都在等待官方的修復，沒有聲張。

 “ 上百萬刀的安全架構，在 Log4J2 漏洞面前一文不值。。。 ” ▼

很快啊，包括了阿里、騰訊、百度、網易、新浪等一眾國內的互聯網大廠紛紛中槍，都被圈在了受影響的範圍之內。

有博主還收到了騰訊雲發來的防護短信。 ▼

不僅僅是大廠的服務系統，耳機、電腦、車機等硬件系統等也無一倖免。。。

不誇張的説，這個漏洞要是不及時修補，下場就是被如飢似渴的黑客們捅爛，進一步威脅網絡安全。

他們會有效利用**“ 零日漏洞 ”**（ 指的是發現後立即被惡意利用的安全漏洞 ）發動零時差攻擊，搶在安全補丁出來之前，對服務器造成殺傷。

就連我們日常使用的手機、電腦軟件（ 大部分都是拿 Java 寫的 ），也都將暴露在黑客的的攻擊範圍內，想捅哪裏捅哪裏，把你的電腦挾持過來挖礦也不是沒可能。

就和打遊戲偷家似的， so easy 。。。

不過有意思的是，也有樂子人利用這個漏洞，發現了特斯拉把國內數據上傳到美利堅服務器的尷尬事兒。

不知道這個數據有沒有包含用户數據，但我建議龍馬哥先別急着解釋這茬了，還是趕緊把這個漏洞修修吧，不然到時候可能真的不好收場。

咳咳，扯遠了。。。

説回這次的漏洞，最可怕的地方在於實現起來沒什麼門檻，只要用一串簡單的字符，就能輕易攻破服務器，並在上面運行各種代碼。。。

這別説是竊取個人信息了，黑客想要遠程挾持、癱瘓企業級的服務器，那也是毫無阻礙。

那黑客到底是怎麼樣利用漏洞，用幾串字符就輕鬆攻破服務器的呢？

要整明白這個問題，我們得先搞清楚啥是日誌。

眾所周知啊，程序員在敲完一段代碼之後，肯定不可能馬上拿來用，而要通過反覆的測試來驗證代碼的可行性。

但代碼本身在跑的時候，處於一個黑箱狀態，如果放任它瞎跑的話，跑到一半卡住，根本不知道是錯在哪一步上。

這就好像是做數學題時候如果沒草稿紙，在心裏算總是沒個底。

這時候，日誌的作用就體現出來了，它就好像是一大張草稿紙，能在上面做任何你自己看的懂得步驟和標記，方便隨時隨地驗算。

本質上日誌是程序員們經常使用的一個工具，它把代碼在測試過程中的每一步都給記錄下來，跑完再回頭 Debug 的時候，就很有針對性，效率也高。

而 Log4J2 ，就是這麼一個開源的日誌框架，它裏面整合了不少在修改代碼時會用到的常用功能，比如日誌管理、輸出變量等實用功能。

這次的高危漏洞就是源於 Log4J2 中一個叫 Lookups 的功能。

從字面上理解，這個功能就是一個用來搜索內容的接口，想要搜些啥，那就要靠代碼去實現了。

Log4J2 也在 Lookups 的功能下，提供了不少實現的途徑，問題就出在這個叫 JNDI 的途徑上。

JNDI 被 Java 允許通過遠程連接的方式來加載文件，這個遠程地址可以是開發者自己的服務器，也可以是外界的服務器。

壞就壞在這個遠程下載上了。。。

黑客只要通過 JNDI 的方法連接上自己的惡意服務器，就可以堂而皇之從這個接口進來，繼而攻破整棟固若金湯的大廈。

這裏世超用儘可能簡單的説法解釋了一下這個漏洞，如果差友們對具體的實現方式有興趣，可以看下知乎上軒轅之風大佬寫的這篇文章，介紹的很詳盡了。

https : //zhuanlan.zhihu.com/p/444103520

那麼問題來了，為什麼這個漏洞在被發現之後過了這麼久，才被重視起來？

外行看熱鬧，內行看門道，有些事兒還真得問問業內人士。

於是世超諮詢了國內知名的白帽網站——火線安全平台的小火子同學，聊了一通之後，大致瞭解了專業人士對這件事兒的看法。

實際上 Log4J2 漏洞產生的原因，是因為部分程序員想要開發者保留在 Lookups 中 JNDI 的實現方式的舊功能而引起的。

根據 Log4J2 的維護者 Volkan Yazıcı 的説法，他們早就想把這個有風險的功能給去了，但為了保證向後的兼容性，照顧到想要用這個功能的程序員，所以還是保留了下來。

**好嘛，小洞不補、大洞吃苦，**這個高危漏洞被發現之後， Log4J2 實際的管理機構 Apache 軟件基金會並沒能引起足夠的重視，披露漏洞的流程也沒有按流程來走。

他們直接把問題往開源平台 Github 的 issue 裏一貼，期待能有好心人給出解決問題得方案。

但這是個開放平台啊，有程序員同樣也有黑客。。。

這波操作等於告訴了全世界的黑客：“ 咱這軟件有高危漏洞哈，歡迎來捅！ ”

甚至在漏洞全面爆發之前，就已經有白客們在 issue 中公開討論過具體的修復細節。

可惜的是，等到所有用到使用 Log4J2 的業務系統反應過來有這個漏洞，已經過去了很長一段時間了。

因為使用 Log4J2 組件的軟件實在太多，所以互聯網公司的安全部門要一個個軟件做修復和升級，這裏頭的工作量也可想而知。

目前最快的臨時處理方案，是在 Log4J2 做一個觸發式的攔截程序，類似於給系統先打上疫苗，把與漏洞相關內容，提前進行阻攔，和防火牆的原理差不多。

話説回來，世超覺得引發這次漏洞問題的鍋，也不應該全由 Log4J2 的維護者來背。

説出來你可能不信，像 Log4J2 這麼大一個開源項目，實際只靠幾個程序員在業餘事件來管理和維護，他們本身也是用愛發電，沒有任何報酬的。

來自 Volkan Yazıcı 推特下網友們的評論▼

與之相反的是，包括像蘋果、谷歌、亞馬遜、特斯拉在內的這些大公司，都一定程度上在開心的**“ 白嫖 ”**Log4J2 ，畢竟開源嘛，能省一點人力維護就省一點，反正總會有人維護的。。。

對於大廠開發者來説，這個來自十幾年前僅有數人在維護的工具，只要能夠完成產品，那湊合用就湊合用了，絕不重複造輪子。

並且爭取在出現問題之前，成功跳槽。。。

可想而知，人人對於這類程序安全漏洞始終都是**“ 碰到了才明白出了問題 ”**，誰知道整個行業都翻了車。

儘管事兒已經是告一段落了，但這樣大型的漏洞翻車事件，並不是第一次，也不會是最後一次發生，此類的**“ 黑天鵝事件 ”**，往往是不可預估且偶發性的。

而這一場場在網絡世界中燃起的大火，唯有依靠程序員們的挑燈夜戰，才得以熄滅。。。

特別鳴謝：火線安全

圖片、資料來源：

微博：@程序員的那些事

微博：@Flanker_017

微博：@主動乾飯貓

知乎：核彈級漏洞！我把log4j扒給你看！

新智元：中國程序員搶先預警「史詩」級漏洞，席捲蘋果特斯拉

開源中國：Log4j 維護者：為向後兼容沒移除導致漏洞的舊功能

Twitter：@yazicivo

Mitigating the log4j Vulnerability (CVE-2021-44228) with NGINX