大家好，我是魚皮，開門見山，知名的開源專案 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；二是在公司做的業務是內部系統，大多數基礎設施和中間件都是內網的，有網路層面的隔離保護；三是我自己的專案用到的服務也都是云服務商提供的，哪怕出了問題，基本也不用自己解決（不過還是存在一定的安全風險就是了），
唉，不知道有多少小伙伴周末要加班了，你躺槍了么？
我是魚皮，原創不易，如果覺得文章還不錯，希望 點贊 支持下，謝謝大家~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/379399.html
標籤：其他
下一篇：一問三不知之log4j2漏洞簡析