CVE-2022-34169 XSLTC bytecode corruption vulnerability

[carlosame]

Felix Wilhelm from Google Project Zero reported CVE-2022-34169:

The Apache Xalan Java XSLT library is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. This can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode.

The Apache Xalan Java project is dormant and in the process of being retired. No future releases of Apache Xalan Java to address this issue are expected.

Note: Java runtimes (such as OpenJDK) include repackaged copies of Xalan.

No more specific details are being shared at this point, but OpenJDK was already patched and the relevant OpenJDK bugs/commits seem to be the following:

Bug	Commit
8285407	openjdk/jdk@41ef2b2
8287916	openjdk/jdk@7b418f9

Analysis

This is clearly a BCEL issue rather than strictly a Xalan one, however the Xalan distribution includes an old version of BCEL as well as other packages. The EchoXSL jar file does not ship BCEL packages (they are an external optional dependency instead) so in principle there is nothing to be done here, except perhaps upgrading BCEL when a new version appears (haven't checked whether the latest BCEL is vulnerable or not).

I'll keep this issue open as a reminder that the BCEL dependency should be checked for safety (and eventually a new version). Meanwhile, it is unclear what the Apache Xalan project is going to do regarding this vulnerability, as they were just discussing about retiring Xalan to the Attic.

[carlosame]

I checked the latest BCEL source code and the class files are essentially the JDK's unpatched ones, so I have to assume that it is vulnerable. No (public) issue has been opened at their issue tracker so far.

[carlosame]

Found the original bug report, which is now public: https://bugs.chromium.org/p/project-zero/issues/detail?id=2290

As part of the compilation process, constants in the XSLT input such as Strings or Numbers get translated into Java constants which are stored at the beginning of the output class file in a structure called the constant pool.

The problem is that neither XSLTC nor BCEL correctly limit the size of the constant pool. As java class files only use 2 bytes to specify the size of the constant pool, its max size is limited to 2**16 - 1 entries (in practice even fewer entries are possible because some constant types take two entries). So what happens if an XSLT stylesheet contains more constants?
BCELs internal constant pool representation uses a standard Java Array for storing constants and does not enforce any limits on its length. When the generated class file is serialized at the end of the compilation process the array length is truncated to a short, but the complete array is written out

The Apache security team was contacted by the CVE reporter back in April.

[carlosame]

The XSLTC fixes in EchoXSL, together with the upgrade to the BCEL 6.7.0 dependency, allows closing this issue.