A crucial flaw in Xalan-J could enable malicious entities to run arbitrary code execution. Xalan-J is an Apache project utilised by several SAML implementations.
The Extensible Stylesheet Language Transformations (XSLT) is a markup language that can change XML documents into other formats, such as HTML. In addition, Xalan-J is a Java version implementation of an XSLT processor.
The project is prone to the effects of an integer truncation issue when processing compromised XSLT stylesheets that a Google Project analyst discovers.
Hackers can exploit the newly discovered issue to corrupt Java class files generated by the internal XSLTC compiler and run arbitrary Java bytecode. The Java class files corruption could allow arbitrary code execution in software via Xalan-J for running untrusted XSLT stylesheets.
Since Xalan-J’s primary function is to perform XSLT transformation during XML signature verification in OpenJDK, the bug could potentially impact numerous Java-based SAML implementations.
SAML is a process of authentication that allows a user to access several web apps using a single set of login credentials.
Researchers explained that there are mitigation practices to avoid getting affected by the Xalan-J critical flaw.
The researchers noted that users could remain unimpacted by the Xalan-J critical flaw if the XSLT support for XML signatures is disabled. XML signatures can be deactivated through the org[.]jcp[.]xml[.]dsig.secureValidation property.
Unfortunately, the default value for apps operating without a SecurityManager was faulty until JDK 17 arrived. Hence, there would be a lot of implementations that will be vulnerable to other attacks.
The analyst revealed that it was able to devise a PoC exploit for the Xalan-J bug that generates a valid class file that an attacker can control. However, the class file is useless for observing how the hackers attack the exploit.
A separate researcher has also produced a different Proof-of-Concept for the vulnerability and posted it on GitHub.
Fortunately, the newly discovered vulnerability has been an ongoing fix in OpenJDK. OpenJDK is an open-source implementation of JDK and Java SE.
However, the leading researcher on this vulnerability noted that its team had not repaired it in Apache’s version.
