Vulnerability in Xalan-J could allow arbitrary code execution

Open source project is used by various SAML implementations

A vulnerability in Xalan-J, an Apache project used by multiple SAML implementations, could allow arbitrary code execution, researchers warn.

XSLT (Extensible Stylesheet Language Transformations) is a markup language that can transform XML documents into other formats, such as HTML.

Xalan-J is a Java version implementation of an XSLT processor.

The project is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets, discovered by Google Project Zero’s Felix Wilhelm.

This issue can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode, he warned, allowing for arbitrary code execution in software using Xalan-J for processing untrusted XSLT stylesheets.

As Xalan-J is used for performing XSLT transformations during XML signature verification in OpenJDK, this bug potentially affects a large number of Java-based SAML implementations, Wilhelm warned.

SAML is a method of authentication that enables a user to access multiple web applications using one set of login credentials.

Mitigations

The researcher noted that XSLT support for XML signatures can be disabled using the org.jcp.xml.dsig.secureValidation property, however the default value for applications running without a SecurityManager was false until JDK 17, “so I would expect a lot of implementations to be vulnerable to this”.

In a blog post published in August, Wilhelm said that he was able to write a Proof-of-Concept (PoC) exploit for this bug “that generates a valid (but useless) class file that’s almost completely controlled by the attacker”.

He continued: “While I haven’t successfully executed my own bytecode yet I’m very confident that this is possible with a bit more time investment, so I am reporting this issue now and may follow-up with a more complete proof-of-concept at a later stage.”

Another researcher has since produced their own PoC for the vulnerability, more details of which can be found on GitHub.

The vulnerability has since been fixed in OpenJDK, the open source implementation of the Java Standard Edition (Java SE) and Java Development Kit (JDK).

Wilhelm notes that it has not been fixed in Apache’s version, which is being retired.