Different SAML implementations make use of open-source initiatives. Researchers caution that a flaw in the Apache project Xalan-J used by numerous SAML implementations leads to arbitrary code execution.
A markup language called XSLT (Extensible Stylesheet Language Transformations) may convert XML files into other forms like HTML.
A Java implementation of an XSLT processor is called Xalan-J.
Felix Wilhelm of Google Project Zero found that the project is susceptible to an integer truncation flaw. This happens when processing malicious XSLT stylesheets.
He cautioned that this Xalan-J vulnerability might be used to execute arbitrary Java bytecode and modify Java class files produced by the internal XSLTC compiler, enabling arbitrary code execution in programmes employing Xalan-J to interpret untrusted XSLT stylesheets.
Wilhelm cautioned that because Xalan-J is used by OpenJDK for XSLT transformations during XML signature verification, this flaw may have a significant impact on many Java-based SAML implementations.
One set of login credentials can be used to access different web apps thanks to the SAML authentication technique.
The researcher pointed out that the org.jcp.xml.dsig.secureValidation property can be used to disable XSLT support for XML signatures. But until JDK 17, the default value for applications running without a SecurityManager was false. So I would expect a lot of implementations to be vulnerable to this.
Wilhelm claimed that he was able to create a Proof-of-Concept (PoC) exploit for this flaw that “generates a legitimate (but worthless) class file that’s nearly totally controlled by the attacker” in a blog post that was published in August.
While I haven’t yet successfully executed my own bytecode, I’m pretty certain that it is achievable with a little more effort investment, so I’m reporting this issue now and may follow-up with a more thorough proof-of-concept at a later date, the author stated.
Since then, the flaw has been resolved in OpenJDK, the open-source implementation of Java Development Kit (JDK). Also, the Java Standard Edition (Java SE) (JDK) has resolved the issue.
Wilhelm observes that despite Apache’s version being decommissioned, it hasn’t been patched.