XMLDecoder解析流程分析

栏目: Java · 发布时间: 5年前

内容简介:经过了Weblogic的几个XMLDecoder相关的CVE(CVE-2017-3506、CVE-2017-10352、CVE-2019-2725),好好看了一下XMLDecoder的分析流程。本文以jdk7版本的XMLDecoder进行分析,jdk6的XMLDecoder流程都写在了一个类里面(com.sun.beans.ObjectHandler)此处只分析XMLDecoder的解析流程,具体Weblogic的漏洞请看其它几位师傅写的Paper。

前言

经过了Weblogic的几个XMLDecoder相关的CVE(CVE-2017-3506、CVE-2017-10352、CVE-2019-2725),好好看了一下XMLDecoder的分析流程。

本文以jdk7版本的XMLDecoder进行分析,jdk6的XMLDecoder流程都写在了一个类里面(com.sun.beans.ObjectHandler)

此处只分析XMLDecoder的解析流程,具体Weblogic的漏洞请看其它几位师傅写的Paper。

WebLogic RCE(CVE-2019-2725)漏洞之旅-Badcode

Weblogic CVE-2019-2725 分析报告-廖新喜

不喜欢看代码的可以看官方关于XMLDecoder的文档: Long Term Persistence of JavaBeans Components: XML Schema

XMLDecoder的几个关键类

XMLDecoder的整体解析过程是基于 Java 自带的SAX XML解析进行的。

以下所有类都在com.sun.beans.decoder包中

DocumentHandler

DocumentHandler继承自DefaultHandler,DefaultHandler是使用SAX进行XML解析的默认Handler,所以Weblogic在对XML对象进行validate的时候也使用了SAX,保证过程的一致性。

DefaultHandler实现了EntityResolver, DTDHandler, ContentHandler, ErrorHandler四个接口。

DocumentHandler主要改写了ContentHandler中的几个接口,毕竟主要是针对内容进行解析的,其它的保留默认就好。

ElementHandler及相关继承类

XMLDecoder对每种支持的标签都实现了一个继承与ElementHandler的类,具体可以在DocumentHandler的构造函数中看到:

XMLDecoder解析流程分析

所以XMLDecoder只能使用如上标签。

其中继承关系与函数重写关系如下(很大,可以看大图或者自己用idea生成再看):

XMLDecoder解析流程分析

如上的继承关系也是object标签可以用void标签替代用的原因,后面详说。

ValueObject及其相关继承类

ValueObject是一个包装类接口,包裹了实际解析过程中产生的对象(包括null)

继承关系:

XMLDecoder解析流程分析

一般的对像由ValueObjectImpl进行包裹,而null\true\false(非boolean标签)则直接由自身Handler进行代表,实现相关接口。

XMLDecoder过程中的几个关键函数

DocumentHandler的XML解析相关函数的详细内容可以参考Java Sax的 ContentHandler的文档

ElementHandler相关函数可以参考ElementHandler的文档。

DocumentHandler创建各个标签对应的ElementHandler并进行调用。

startElement

处理开始标签,包括属性的添加 DocumentHandler: 。XML解析处理过程中参数包含命名空间URL、标签名、完整标签名、属性列表。根据完整标签名创建对应的ElementHandler并添加相关属性,继续调用其startElement。

ElementHandler:除了array标签以外,都无操作。

endElement

结束标签处理函数 DocumentHandler: 调用对应ElementHandler的endElement函数,并将当前ElementHandler回溯到上一级的ElementHandler。

ElementHandler:没看有重写的,都是调用抽象类ElementHandler的endElement函数,判断是否需要向parent写入参数和是否需要注册标签对象ID。

characters

DocumentHandler:标签包裹的文本内容处理函数,比如处理 <string>java.lang.ProcessBuilder</string> 包裹的文本内容就会从这个函数走。函数中最终调用了对应ElementHandler的addCharacter函数。

addCharacter

ElementHandler:ElementHandler里的addCharacter只接受接种空白字符(空格\n\t\r),其余的会抛异常,而StringElementHandler中则进行了重写,会记录完整的字符串值。

addAttribute

ElementHandler:添加属性,每种标签支持的相应的属性,出现其余属性会报错。

getContextBean

ElementHandler:获取操作对象,比如method标签在执行方法时,要从获取上级object/void/new标签Handler所创建的对象。该方法 一般 会触发上一级的getValueObject方法。

getValueObject

ElementHandler:获取当前标签所产生的对象对应的ValueObject实例。具体实现需要看每个ElementHandler类。

isArgument

ElementHandler:判断是否为上一级标签Handler的参数。

addArgument

ElementHandler:为当前级标签Handler添加参数。

XMLDecoder相关的其它

两个成员变量,在类的实例化之前,通过对parent的调用进行增加参数。

parent

最外层标签的ElementHandler的parent为null,而后依次为上一级标签对应的ElementHandler。

owner

ElementHandler:固定owner为所属DocumentHandler对象。

DocumentHandler:owner固定为所属XMLDecoder对象。

简易版解析流程图

PPT画的:-D

XMLDecoder解析流程分析

跟着漏洞来波跟踪(Weblogic)

来一份简单的代码:

public static void main(String[] args) throws FileNotFoundException {
    String filename = "1.xml";
    XMLDecoder XD =new XMLDecoder(new FileInputStream(filename));
    Object o = XD.readObject();
    System.out.println(o);
}

Level1:什么过滤都没有

<java>
    <object class="java.lang.ProcessBuilder">
        <array class="java.lang.String" length="1">
            <void index="0">
                <string>calc</string>
            </void>
        </array>
        <void method="start"/>
    </object>
</java>

首先看下DocumentHandler的startElement: XMLDecoder解析流程分析 1. 创建对应Handler,设置owner与parent 2. 为Handler添加属性 3. 调用Handler的startElement

(后面DocumentHandler的部分忽略,直接从ElementHandler开始) 下面从object标签对应的ObjectElementHandler开始看: 进入obejct标签,object标签带有class属性,进入: XMLDecoder解析流程分析 可以看到判断的列表里没有class标签,会调用父类(NewElementHandler)的addAttribute方法。 XMLDecoder解析流程分析 给type赋值为java.lang.ProcessBuilder对应的Class对象。

中间创建array参数的部分略过,有兴趣的同学可以自己跟一下。

进入void标签,设置好method参数,由于继承关系,看上面那张addAttribute图就好。

退出void标签,进入elementHandler的endElement函数: XMLDecoder解析流程分析

由于继承关系,调用NewElementHandler的getValueObject函数: XMLDecoder解析流程分析

继续进入进入ObjectElementHandler的带参数getValueObject函数: XMLDecoder解析流程分析 此处的getContextBean会调用上一级也就是Object标签的getValueObject来获取操作对象。

略过中间步骤,再次进入ObjectElementHandler的getValueObject方法:

最终通过Expression创建了对象: XMLDecoder解析流程分析 (可以看出此处的Expression的首个参数是来自于上面getContextBean获取的Class对象,先记住,后面会用)

再次回到Void标签对应的getValueObject函数: 最终通过Expression调用了start函数: XMLDecoder解析流程分析

如果对继承关系感觉比较蒙的话,可以看下一节的继承关系图。

PS:虽然ObjectElementHandler继承自NewElementHandler,但是其重写了getValueObject函数,两者是使用不同方法创建类的实例的。 再PS: 其实不加java标签也能用,但是没法包含多个对象了。

Level2:只过滤了object标签

把上面的object标签替换为void即可。

VoidElementHandler的继承关系:

XMLDecoder解析流程分析

可以看到只改写了isArgument,而在整个触发过程中并无影响,所以此处使用void标签与object标签完全没有区别。

Level3:过滤一堆

过滤了object/new/method标签,void标签只允许用index,array的class只能用byte,并限制了长度。

CNVD-2018-2725(CVE-2019-2725)最初的poc使用了UnitOfWorkChangeSet这个类,这个类的构造方法如下(从Badcode师傅的Paper里盗的图):

XMLDecoder解析流程分析

最初的poc主要利用 UnitOfWorkChangeSet 类在构造函数中,会将输入的byte数组的内容进行反序列化,所以说刚开始说是反序列化漏洞。

其实这个洞是利用了存在问题的类的构造函数,因为没法用调用method了,就取了这种比较折中的方法。(其实还是有部分方法可以调用的:-D)。

在做这个实验时需要导入weblogic 10.3.6的modules目录下com.oracle.toplink_1.1.0.0_11-1-1-6-0.jar文件。

<java>
    <class><string>oracle.toplink.internal.sessions.UnitOfWorkChangeSet</string><void>
            <array class="byte" length="2">
                <void index="0">
                    <byte>-84</byte>
                </void>
                <void index="0">
                    <byte>-19</byte>
                </void>
            </array>
        </void>
    </class>
</java>

由于class标签继承了继承了string标签的 addCharacter 函数,导致其会将标签中包裹的空白字符(空格\r\n\t)也加入到classname中,导致找class失败,所以至少要将\<class>到\<void>之间的空白字符删除。

PS:其实这里不加string标签也没问题。

Level1中说到:

Expression的首个参数是来自于上面getContextBean获取的Class对象

也就是说,如果能够找到替代上面object/void+class属性的方法令getContextBean可以获取到Class对象,也久可以调用构造函数进行对象的创建。

我们来看下此处调用的getContextBean的实现: XMLDecoder解析流程分析

Level1/2中由于Object(Void)设置了class属性,那么type是有值的,所以直接返回type。

而父类的getContextBean是调用parent的getValueObject函数,来获取上一级对象,所以此时我们令上一级获取到的对象为Class即可,所以此处使用了class标签令void的上一级获取的对象为Class对象。

因为void标签只允许使用index属性,所以此处无法使用method属性来调用具体函数,所以只能寄期望于构造方法,就有了上面利用UnitOfWorkChangeSet类的构造方法来利用反序列化漏洞的手法。

同样可利用的类还有之前 jackson rce 用的FileSystemXmlApplicationContext类。

总结

XMLDecoder的流程还是蛮有意思的,具体各标签的功能、详细解析流程,还需要大家自己看一下。

顺便重要的事情说三遍: 一定要自己跟一下! 一定要自己跟一下! 一定要自己跟一下!


以上所述就是小编给大家介绍的《XMLDecoder解析流程分析》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

轻量级Django

轻量级Django

茱莉亚·埃尔曼 (Julia Elman)、马克·拉温 (Mark Lavin) / 侯荣涛、吴磊 / 中国电力出版社; 第1版 / 2016-11-1 / 35.6

自Django 创建以来,各种各样的开源社区已经构建了很多Web 框架,比如JavaScript 社区创建的Angular.js 、Ember.js 和Backbone.js 之类面向前端的Web 框架,它们是现代Web 开发中的先驱。Django 从哪里入手来适应这些框架呢?我们如何将客户端MVC 框架整合成为当前的Django 基础架构? 本书讲述如何利用Django 强大的“自支持”功......一起来看看 《轻量级Django》 这本书的介绍吧!

随机密码生成器
随机密码生成器

多种字符组合密码

MD5 加密
MD5 加密

MD5 加密工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具