周五的時候感覺整個安全圈都炸了，沒想到打個log還能暴露出漏洞來，真的是活見鬼了。不過在我看來，這真的沒有什么了。（本人見慣風雨）。
Log4j2提供了lookup功能，該功能允許開發者通過一些協議去讀取相應環境中的配置。但是對輸入並未進行嚴格的判斷，造成了可以被利用的風險。
詳細的內容可以參考： https://www.lunasec.io/docs/blog/log4j-zero-day
喜歡用docker的同學也可以體驗一把，定個小目標，怎么去那個打log的機器先放個文件 https://github.com/christophetd/log4shell-vulnerable-app
我周五反正是搞到了凌晨三點多，一方面是本地測試一下，看看這個漏洞是怎么玩的。本地搭好了之后就是測試一下那些所謂的暴露條件是不是真實有效的：
比如說 Log4j 2.0 到 2.14.1 都有問題
在比如說 JDK 版本大於 6u211, 7u201, 8u191, 11.0.1 也可以避免問題
隨機測試了幾個，確實是這樣的。 接下來是看看這樣的問題對本公司所造成的影響到底有多大。那么好， 我們就去github搜索 對應的log4j的版本吧， JDK也看了一下， 對應的update不行。也就是說一旦用了Log4j 2.0 到 2.14.1就可能有問題了。
然后是各種代碼審閱。。。可以確定的是，即使你打log了， 只要你所打的log對應的變量里邊不可能被黑客通過任何手段傳入 jndi:ldap// 或着 jndi:rmi// 的話， 其實也還是安全的。 總之看了一圈，沒發現什么問題。懶惰有時候也是好事情， 我們很多log4j都還在1.X版本。（不過也是存在另外一個high基本的漏洞 - CVE-2019-1757） 汗顏啊， 也是一個遠程代碼執行。。。不過不是撞在現在的風頭了 （就是那種臉上， 你看， 都已經存在N年了，怎么去改？已知問題敷衍了事）
接下來覺得可能還不夠保險， 去對應Jfrog的管理里邊去查看一下對應的log4j2包所被引用的構建。然后才放心了。當然這種放心是不夠徹底的。最好的做法還是應該先來個斷后，網上已經有對應的解決方案：
1. 修改jvm Dlog4j2.formatMsgNoLookups=true
2. 修改配置 log4j2.formatMsgNoLookups=True
3. 系統環境變量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS = true
檢測方案還有DNSLog域名請求的攔截，讓遠程call找不到回家的路。還有日志系統里邊去查詢 jndi:ldap: 或者 jndi:rmi等字符來判斷被攻擊的指數。
安全問題真的是動態的，所有道高一尺魔高一丈。同時也覺得似乎大家對安全的重視還不夠，即便是很資深的程序猿也很有可能去忽視這方面的問題。作為公司的管理層，其實真的要把安全定位在很高的程度。否則真的不知道什么時候樓就塌了。