Xalan

本文是对CVE-2022-34169的学习，主要参考thanat0s大佬的文章这是第一次遇到与 Java Class 字节码相关的漏洞，漏洞类型有点偏向于二进制溢出漏洞。在分析漏洞过程中加强了对Java字节码的了解，学到了很多。后面也尝试并成功构造了JDK-Xalan的paylod。

可扩展样式表转换语言（英语：Extensible Stylesheet Language Transformations，缩写XSLT）是一种样式转换标记语言，可以将XML资料档转换为另外的XML或其它格式，如HTML网页，纯文字。XSLT最末的T字母表示英语中的“转换”（transformation）。它是XSL规范中的一部分，目前最新的建议版本为XSL 3.0。

Xalan-J 是 Apache 开源项目下的一个 XSLT 处理器的 Java 版本实现

Xalan-Java 即时编译器(JIT) 会将传入的 XSLT 样式表使用 BCEL 动态生成 Java Class 字节码文件(Class 文件结构如下)，XSLT 样式表中的字符串(String) 以及 >32767 的数值将存入到字节码的常量池表(constant_pool) 中。漏洞产生的原因在于 Class 字节码规范中限制了常量池计数器大小(constant_pool_count) 为 u2 类型(2个无符号字节大小)，所以 BCEL 在写入 > 0xffff(65535)数量的常量时需要进行截断处理，但是通过上面 dump() 方法中的代码可以看到，BCEL 虽然对 constant_pool_count 数值进行了处理，但实际依旧写入了 > 0xffff 数量的常量，因此大于 constant_pool_count 部分的常量最终将覆盖 access_flags 及后续部分的内容

可以使用 Java 自带的工具 javap 查看字节码文件中的常量池内容：javap -v select.class也可以使用 Classpy GUI 工具进行查看，该工具在点击左侧相应字段信息时会在右侧定位出相应的十六进制范围，在构造利用时提供了很大的帮助但是这两个工具无法对首部结构正确的畸形字节码文件进行解析(只输出正确结构的部分)，并且未找到合适的解析工具

常量池表中具体存储的数据结构如下，根据 tag 标识来决定后续字节码所表达的含义：

根据参考文章测试分析得出结论：

具体原因：尝试在 select.xslt 文件中添加 并生成 Class 文件。查看Class文件字节码可以发现，对应到常量池中实际将增加 CONSTANT_String_info 和 CONSTANT_utf8_info 两项，其中 #092(CONSTANT_utf8_info) 中存储着字面量 AAA，#093(CONSTANT_String_info) 的 string_index 则指向 AAA 字面量所处的下标。为了节省空间，对于相同的常量在常量池中只会存储一份，所以如下内容所生成的 Class 文件中的常量池计数器值依旧为 139

需要注意的是 AA 和 AAA 实际属于不同的常量，将得到的常量池计数器值为：139+2=141，因此：使用不同的字符串可以 字符串数量x2 的形式增加常量池计数器的值

这里先展示一下整个 Class 文件最终构造的结构图，接下来将针对各个部分进行说明

想详细了解 Java Class 字节码文件结构的可以参考链接：The Class File Format

access_flags 第一个字节对应常量池的 tag，而 tag 值将决定后续的数据结构(查阅前面常量池结构表)access_flags 的值决定了类的访问标识，如是否为 public ，是否为抽象类等等，如下为各个标识对应的mask 值，当与操作值 != 0时则会增加相应的修饰符在确定 access_flag 第一个字节的值(后续使用x1,x2..代替)之前，需要知道编译后的字节码会被进行怎样的处理。可以看到最终将得到 TemplatesImpl 对象，其中 _bytecodes 即为 XSLT 样式表编译后的字节码内容，熟悉 Java 反序列化漏洞的应该对 TemplatesImpl 类不陌生，之后 newTransformer() 方法调用将会触发 defineClass() 及 newInstance() 方法的调用由于 defineClass() 过程无法触发类 static{} 方法块中的代码，所以需要借助 newInstance() 调用的过程来触发static{}、{}、构造函数方法块中的恶意代码，因此由于需要实例化类对象，所以类不能为接口、抽象类，并且需要被 public 修饰，所以 access_flags 需满足如下条件：

这里选择设置 access_flags.x1 = 0x08，不选择 access_flags.x1 = 0x01 的原因在于字面量 length 变化会影响到 bytes 的数量，所以一旦发生变动，后续内容就会需要跟着变动，不太好控制。而 access_flags.x2 的值这里将其设置为 0x07，而不使用 0x01 的原因在于，其值的设定会影响到常量池的大小，根据后续构造发现常量池大小需要满足 > 0x0600(1536) 大小，这部分后续methods[1].attributes[0]也会再进行说明

通过写入 tag = 6 的 double 数值常量(java.lang.Math#ceil(double))，可以实现连续控制 8 个字节内容，可借助如下脚本实现十六进制转换：

所以 this_class.x2 = 0x06，根据前面可知，this_class 是一个指向常量池的 常量池索引，所以为了使得截断后的常量池最小，所以这个值需要尽可能的小，由于0x0006这个常量池已经被占用了，无法进行截断，所以最终确定值为 this_class = 0x0106(262)

这里的08070106中的0701还有另一层含义：String 类型的 string_index 指向前一项 Utf8 字面量的下标，因此 tag = 8 string_index = 0x0701 则表示前一项是下标为 0x0701 = #1793 的 Utf8 字面量，当前下标为 #1794，所以得出结论是 access_flags 之前应有 1794(包含第 0 项) 个常量，则 constant_pool_count 截断后的值固定为 1794(0x0702)，access_flags.x2 间接控制了常量池的大小（此时constant_pool_count的值应为0x0702，所以到t1051处截断，下面的字节就不是常量池里的内容了，直接赋值给access_flags及之后的字段）

根据字节码规范要求，this_class 应指向一个 CONSTANT_Class_info 结构的常量，也即如下图中 Class 对应的下标#0006但是这里并不能选择常量池已有的这些Class常量，原因在于这些Class常量是XSLT解析的过程中会使用到的类，而字节码最终会被defineClass()加载为Class，将会导致类冲突问题（TODO：为啥会导致类冲突？）解决方法是通过如下方法调用的方式加载一些XSLT解析过程不会引用的类，因为类是懒加载的，只有在被使用到的时候才会被加载进JVM，所以defineClass()调用时并不会存在com.sun.org.apache.xalan.internal.lib.ExsltStrings，从而解决了类冲突的问题，之后通过在其之前填充一些常量，使得 this_class = 0x0106(#262) 刚好指向 (Class): com/sun/org/apache/xalan/internal/lib/ExsltStrings 即可。

super_class 同样也需要指向 CONSTANT_Class_info 类型索引，并且因为 TemplatesImpl 的原因依旧需要继承 org.apache.xalan.xsltc.runtime.AbstractTranslet 抽象类，所以直接指向 #0006 即可(位置固定不变)因为主要目的是控制方法，并通过 newInstance() 触发恶意代码，所以对于接口和字段都可以不需要，直接设置为 0 即可：

经测试发现 static{} 方法块()执行必须要有合法的构造函数存在，所以直接通过触发恶意代码即可，除此之外还需要借助一个方法的attribute部分进行一些脏字符的吞噬(后续解释)，所以类中至少需要 2 个方法。经测试发现：在字节码层面，非抽象类可以不实现抽象父类的抽象方法，所以可以不实现抽象父类 AbstractTranslet 的 transform 方法，设置 method_count = 0x0002 即可

首先看到 method_info 结构：

根据前面的构造可以看到 methods[0].access_flags.x1 = 0x06，根据访问标识表可知当前方法为抽象(0x06 & 0x04 != 0) 方法，无法包含方法体，所以这也是至少需要存在两个方法的原因，但同时也发现一个问题：在字节码层面，抽象方法是可以存在于非抽象类中的

methods[0].attributes_count 表示当前方法体中attribute的数量，每个attribute都有着如下通用格式，根据attribute_name_index来决定使用的是哪种属性格式(如下表)

这里主要关注 Code 属性，其中存储着方法块中的字节码指令

以如下代码为例查看相应的 Code 属性结构

可以看到构造函数中attributes_count = 1说明只包含一个属性，attribute_nam_index指向常量池#10(Utf8) Code，表示当前为Code属性，code_length 表示字节码指令长度为 17，code 部分则存储了具体的字节码指令这里需要注意的是：如果attribute_name_index没有指向合法的属性名，将使用通用格式来进行数据解析，因此可以利用这个特性来吞噬下一个double常量的tag标识，因此这里设定

接下来看到第二个方法methods[1]，首部这 8 个字节就可直接通过一个 double 数值类型进行控制，这里将构造所需的构造函数方法：

可以看到 methods[1].attributes[0].attribute_name_index.x1 = 0x06，是为了设置double的tag，又因为 attribute_name_index 是指向常量池的索引，所以需要常量池需要 > 1536(0x0600)，这就是前面 access_flags.x2 >= 0x06 的原因使用同样的方式，通过控制 attributes[0].attribute_length 吞噬掉下一个 double 常量的 tag这样就可以完全控制 attributes[1].attribute_name_index，使其指向Utf8 Code常量，后续数据将以Code_attribute结构进行解析

这里提前看到 methods[1].attributes[2].attribute_name_index 字段，因为 attributes[2] 的作用也是用于吞噬后续的垃圾字符，所以可以和 methods[0].attributes[0].attribute_name_index 一样设置为 0x0206，所以 code 尾部需要有 3 个字节是位于 double 常量首部的

接着看到最重要的字节码指令构造部分，可以通过Java字节码指令列表获取相关的 Opcode并非需要每个字节挨个自行进行构造，可以直接编写一个恶意方法，然后提取其中 code 字节码指令部分即可，编写如下代码并获取其字节码指令：

根据上面的字节码指令即可构造出如下代码结构，其中有几点需要注意：

对于 Methodref 方法引用类型，可以使用如下方法调用的方式进行添加

但是这里唯一存在问题的是：如何添加AbstractTranslet.方法引用，这里需要看到org.apache.xalan.xsltc.compiler.Stylesheet#translate()方法，构造函数总是最后才进行编译，添加的AbstractTranslet.方法引用总是位于常量池末尾，所以这将导致截断后的常量池中很难包含MethodRef: AbstractTranslet.方法引用然而构造函数中必须要调用super()或this()方法，否则会报错。这里有两种解决办法：

同样通过控制 attribute_length 长度吞噬掉剩余的垃圾字符，由于需要保留 ClassFile 尾部的 SourceFile 属性，所以长度设置为：从 0x12345678 -> 保留尾部 10 个字节(attributes_count + attributes)，至此完整的利用就构造好了

这里总结一下需要检查的一些项：

对于JDK-Xalan paylod的构造主要参考于JDK-Xalan的XSLT整数截断漏洞利用构造同时对工具进行了debug，包括但不限于修复了常量池长度大于0x0702时的处理异常、初始payload不存在标识位等情况。最终成功在mac上实现了payload的自动生成项目地址https://github.com/altEr1125/AutoGenerateXalanPayload