Xmldecoder学习之路

之前看到@fnmsd师傅关于xmldecoder的解析流程分析文章《 XMLDecoder解析流程分析 》，然后我就想着自己也跟一下，我测试的java版本是1.8.0_171。

0x02 测试代码

import java.io.BufferedInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.beans.XMLDecoder;

public class Xmldecoder {

public static void XMLDecode_Deserialize(String path) throws Exception {
File file = new File(path);
FileInputStream fis = new FileInputStream(file);
BufferedInputStream bis = new BufferedInputStream(fis);
XMLDecoder xd = new XMLDecoder(bis);
xd.readObject();
xd.close();
}


public static void main(String[] args){
//XMLDecode Deserialize Test
String path = "/Users/l1nk3r/Desktop/poc.xml";
try {
XMLDecode_Deserialize(path);
} catch (Exception e) {
e.printStackTrace();
}
}
}

0x03 前置知识

这里我选择在 java.lang.ProcessBuilder 接收 array 类型数据传入的地方下个断点。

可以看到整个解析流程涉及到的类和构造方法大概就是如下所示，这里我们看到一个在 package:com.sun.beans.decoder 中 DocumentHandler 类中 parse 解析了，我们的传入的xml文件。

这里可以跟进一下 DocumentHandler 类，这个类继承了 DefaultHandler 。

跟进一下 DefaultHandler 类，我们可以知道它是使用 sax 来解析 xml 的默认 handler ，而且代码里来看它主要实现了 EntityResolver , DTDHandler , ContentHandler , ErrorHandler 这四个 handler 。

package org.xml.sax.helpers;
import java.io.IOException;
import org.xml.sax.InputSource;
import org.xml.sax.Locator;
import org.xml.sax.Attributes;
import org.xml.sax.EntityResolver;
import org.xml.sax.DTDHandler;
import org.xml.sax.ContentHandler;
import org.xml.sax.ErrorHandler;
import org.xml.sax.SAXException;
import org.xml.sax.SAXParseException;

/**
* Default base class for SAX2 event handlers.
*
...
public class DefaultHandler
implements EntityResolver, DTDHandler, ContentHandler, ErrorHandler
{

回过头来看 DocumentHandler 这个类，在这个类的构造方法中，我们看到了 XMLDecoder 对每种支持的标签都实现了一个继承与 ElementHandler 的类。

所以从目前来看 DocumentHandler 这个构造函数主要的作用就是创建各个标签对应的 ElementHandler 并进行调用。当然关于 DocumentHandler 类因为是继承了 DefaultHandler 类，这一点我们前面聊到了，而 DefaultHandler 类中解析xml的工作主要交付给了 ContentHandler 接口，所以我们可以借鉴一下这个接口是怎么个解析xml内容的，相关内容可以参考Java Sax的 ContentHandler的文档 ，这里直接借鉴一下@fnmsd师傅写的内容，因为我觉得我自己写的话没有他写的这么的棒。

而sax解析xml文件中的单个node节点（根节点）的流程在 DefaultHandler 中一般是三步走: startElement->characters->endElement 。

针对node节点（非根）的解析流程在中是四步走 DefaultHandler 中一般是四步走: startElement->characters->endElement->characters。

所以总结来看本质上最有关系的还是这三个构造方法 startElement、characters、endElement 。

然后，我们可以看看 DocumentHandler 中的这些 ElementHandler 的继承关系，这里重点表扬一下 idea 的 uml 的功能，使用方法很简单，选择一个你想要看的方法，右键选择 Diagrams 。

然后每次选择 add Class to Diagram 就可以增加你要看的相关类。

最后就生成了下面这张图。

而关于xmldecoder对应的xml文件语法书写如下所示：

• 每个元素表示方法调用。
• “对象”标签表示一个 表达式 ，其值将用作封闭元素的参数。
• “void”标签表示将被执行的语句 ，但其结果将不会用作封闭方法的参数。
• 包含元素的元素使用这些元素作为参数，除非它们具有标签：“void”。
• 方法的名称由“method”属性表示。
• XML的标准“id”和“idref”属性用于对前面的表达式进行引用，以便处理对象图形中的循环。
• “类”属性用于明确指定静态方法或构造函数的目标; 其值是该类的完全限定名称。
• 如果没有由“class”属性定义目标，则使用“void”标签的元素将使用外部上下文作为目标来执行。
• Java的String类被特别处理，并写入
  
  Hello，world ，其中使用UTF-8字符编码将字符串的字符转换为字节。
  

0x04 流程跟进

这里跟进一下上面的那些基础知识分析过的内容，首先按照我们的了解来看，针对xml文件的解析最早应该是使用 DefultHandler 中 startElement ，我们在这里下个断点。

回过头来看一下xml文件内容，最开始的节点叫java，所以这里解析出来对应的对应的 handler 是 JavaElementHandler 。

而 JavaElementHandler 中的 addAttribute 构造函数的作用就是添加相应的属性，比如 version 的属性是版本信息这里是 1.8.0_131 ，而另一个就是 class 这里是 java.beans.XMLDecocer 。

public void addAttribute(String var1, String var2) {
if (!var1.equals("version")) {
if (var1.equals("class")) {
this.type = this.getOwner().findClass(var2);
} else {
super.addAttribute(var1, var2);
}
}

所以开始第一次 addAttribute 的结果是 version 和它对应的值，当然这个解析过程不是一次，单单是下面内容就会执行两次解析过程。

java version="1.8.0_131" class="java.beans.XMLDecoder"

当然关键不在这，我想知道为什么能够执行 java.lang.ProcessBuilder 这个类，从前面debug过程来看，如果。 startElement 解析道这里处理之后对应的 handler 应该是 ObjectElementHandler 。

在这里下一个断点，果然进来了， ObjectElementHandler 里面的 addAttribute 方法没有能够解析 class 的选项。

但是由于 ObjectElementHandler 继承了 NewElementHandler ，所以这里便使用 NewElementHandler 中的 addAttribute 方法来处理，这里自然有了能够处理 class 的能力了。

这里的 type 自然就是名字是 java.lang.ProcessBuilder 的类。

这里处理完了之后就会继续调用 ArrayElementHandler 处理 array 的内容了，然后调用 VoidElementHandler 处理 void 标签的内容，而 VoidElementHandler 也是继承来自于 ObjectElementHandler ，自然而然也是回到了 ObjectElementHandler 中的 addAttribute 中了。

这里我就下了两个断点，我们可以看到 void 标签中的 index 和 method 处理过程自然都进入到了这里。

当然前面过程 void 标签处理完之后，首先会进入 DocumentHandler 的 endElement 方法进行处理，而这个方法中调用了 ElementHandler 中的 endElement 构造方法。

//DocumentHandler
public void endElement(String var1, String var2, String var3) {
try {
this.handler.endElement();
} catch (RuntimeException var8) {
this.handleException(var8);
} finally {
this.handler = this.handler.getParent();
}
}

而在 endElement 构造方法中调用了 getValueObject ，这个方法设置了在 endElement 中被设置成了一个抽象类，我们通过在 java.lang.ProcessBuilder 处下一个断点，可以看到自然进到了 NewElementHandler 中的 getValueObject 了。

public void endElement() {
ValueObject var1 = this.getValueObject();
if (!var1.isVoid()) {
if (this.id != null) {
this.owner.setVariable(this.id, var1.getValue());
}

if (this.isArgument()) {
if (this.parent != null) {
this.parent.addArgument(var1.getValue());
} else {
this.owner.addObject(var1.getValue());
}
}
}
}

再回顾一下继承关系，这里我放大了一下这部分内容。

上面的 NewElementHandler 中的构造方法 getValueObject 在 ObjectElementHandler 、 ArrayElementHandler 、 MethodElementHandler 中分别被重写了。

因为我们 payload 里面关于命令执行使用的是 object 标签，所以自然就进来到了 ObjectElementHandler 中，然后这里有调用了 getContextBean 方法，而根据继承关系，这个方法调用的是 NewElementHandler 中的 getContentBean 方法

protected final Object getContextBean() {
return this.type != null ? this.type : super.getContextBean();
}

而 NewElementHandler 中的 getContextBean 方法又是因为继承关系调用了来自于 ElementHandler 中的 getContextBean 方法。

protected Object getContextBean() {
if (this.parent != null) {
ValueObject var2 = this.parent.getValueObject();
if (!var2.isVoid()) {
return var2.getValue();
} else {
throw new IllegalStateException("The outer element does not return value");
}
} else {
Object var1 = this.owner.getOwner();
if (var1 != null) {
return var1;
} else {
throw new IllegalStateException("The topmost element does not have context");
}
}

而这里的 getValueObjcet 操作根据我的断点执行了两次。

我们可以看一下结果，第一次进入 NewElementHandler 中进行 getValueObject 实际上在 type 里面是没有 class 的值的。而第二次进入 NewElementHandler 中进行 getValueObject 操作的时候 type 是取到相关的 class 的值。

那么根据上面所说这里势必会进入到 ObjectElementHandler 中的 getValueHandler 方法进行处理，而在这个方法的最后是调用了 Expression 中的 getValue 方法，这里可以看到我们要执行的命令以及 class 对象都已经传入了。

而进一步动态调试我们可以看到 Expression 中的 getValue 已经返回我们需要的命令执行对象类，以及命令参数了。

然后会重新回到 Void 标签对应的 getValueObject 函数，由于 ViodElementHandler 继承 ObjectElementHandler ，而我们这里设置的 method 等于 start ，因此这里通过 Expression 的反射机制调用了 start 函数，所以到这里自然命令执行了。

这个是从师傅文章里看到的小贴士，自己跟下来之后确实是这样

PS:虽然ObjectElementHandler继承自NewElementHandler，但是其重写了getValueObject函数，两者是使用不同方法创建类的实例的。

再PS:其实不加java标签也能用,但是没法包含多个对象了。

0x05 补丁

Oracle关于这个xmldecoder造成的漏洞的CVE编号分别是CVE-2017-3506、CVE-2017-10271、CVE-2019-2725。最早关于CVE-2017-3506的补丁只是根据Object标签进行了限制。

而根据我们前面的继承关系可以讲 object 替换成 void 即可，它们实际上是不受影响的，因此便出现了CVE-2017-10271，而针对CVE-2017-10271的补丁限定了所有具有执行的节点。

但这次 CVE-2019-2725 主要是 class 标签，class 标签可代替 object 标签来生成对象，因此这次漏洞本质还是xmldecoder的问题，而补丁也是针对class标签来处理的。