大家好，我是魚皮，開門見山，知名的開源項目 Apache Log4j 出事了！
2021 年 12 月 9 日，該項目被曝存在 嚴重安全漏洞 ，攻擊者只需要向目標機傳入一段特殊代碼，就能觸發漏洞，自由地在遠程執行任意代碼來控制目標機器！
老實說，光聽到這個消息，我就覺得很可怕了。因為 Log4j 作為 Java 的知名日志記錄框架，憑借其靈活高效的日志生成能力，不僅被眾多自研項目所使用，還被很多明星項目作為了基礎框架使用，像 Redis、Kafka、Elasticsearch、Apache Flink、Apache Druid 等等。可以想象這個漏洞的影響范圍有多大，甚至被很多媒體稱之為 “核彈級” 漏洞！
在漏洞被曝光之后，第一時間做出行動的不是無辜躺槍的程序員們，而是那些壞的一批的小子們。據說，在漏洞被公開的第一天，就發生了近萬次利用該漏洞的攻擊行為！
漏洞細節
根據 CVE 漏洞公開網站的記錄，該漏洞存在於 Apache log4j <= 2.14.1 的版本（但事實上，影響的版本范圍比這更大）。攻擊者可以通過 log4j 的 lookup 替換功能向其配置文件的任意位置注入代碼（類似 SQL 注入，把 ${變量} 替換為 ${實際代碼}），再加上這些版本中用到的 JNDI 特性並沒有為 LDAP 提供足夠的保護，使得注入的任意代碼都能被肆無忌憚地執行。
JNDI：Java 命名與目錄接口，提供了用名稱來訪問資源的能力
LDAP：輕型目錄訪問協議，定義了如何訪問目錄服務中的內容
兩者配合，可以完成對服務器目錄的操作，比如增刪改查。
有一些用 Minecraft Java 版本開服的小伙伴就被坑了，因為該項目用到了 log4j 來記錄用戶聊天日志，因此玩家只需要在聊天窗口輸入一些這個那個的命令代碼，就被注入執行了，從而輕松作弊。
解決方案
我整理了三種解決方案，可以根據實際情況選用。
1. 升級版本
目前 Apache 官方已經針對該漏洞發布了補丁版本 2.15.0-rc2，默認禁用了 lookup 行為，在確保升級該版本不會對項目的其他依賴產生沖突的情況下，建議升級。
該方案雖然比較簡單粗暴，但這個版本是否穩定？是否沒有漏洞呢？這很難說。
2. 修改參數
如果你不想升級 log4j 的版本，擔心會和項目其他依賴產生沖突的話，可以采用 Apache 官方推薦的臨時解決方案 —— 修改參數。
如果你的 log4j 版本 >= 2.10，可以通過設置系統屬性 log4j2.formatMsgNoLookups 或者環境變量 LOG4J_FORMAT_MSG_NO_LOOKUPS 為 true 來禁用 lookup 行為；如果版本在 2.0-beta9 到 2.10.0 之間， 可以直接移除從 classpath 中移除 JndiLookup 類，用以下命令即可：
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
這個方案相對不容易引發項目的沖突，如果項目很緊急且重要，先用它處理吧。
3. 換框架
最暴力、也是解決最徹底的方案就是干脆不用 log4j 了，用別的！
比如我自己很早之前就棄用 log4j，改用 logback 了，不說別的，logback 的測試更加充分，質量相對有保障一些。畢竟日志框架作為一個項目必備的核心依賴，穩定性是至關重要的。
當然，這種方式對項目的影響可能會很大，如果一定要整體替換框架，建議進行充分的測試（覆蓋率越高越好），可不是改幾行代碼那么簡單。
最后魚皮再多說幾句吧，這次的事件又印證了軟件開發中的 不信任原則 ，沒有絕對可信、完全不出問題的服務，所以我們開發者要做的就是時刻多留一個心眼兒，盡量針對一些服務的不穩定去設計一些保護或降級措施。比如假設分布式緩存會掛掉，可以再設計本地緩存繼續提供臨時服務，保障系統的可用性。
不過還好這次漏洞對我沒什么影響，一是項目本身沒用 log4j 而是 logback；二是在公司做的業務是內部系統，大多數基礎設施和中間件都是內網的，有網絡層面的隔離保護；三是我自己的項目用到的服務也都是雲服務商提供的，哪怕出了問題，基本也不用自己解決（不過還是存在一定的安全風險就是了）。
唉，不知道有多少小伙伴周末要加班了，你躺槍了么？
我是魚皮，原創不易，如果覺得文章還不錯，希望 點贊 支持下，謝謝大家~