CVE-2022-34169 XSLTC bytecode corruption vulnerability about echoxsl HOT 3 CLOSED

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.

from echoxsl.

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.

from echoxsl.

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

from echoxsl.