Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.7.3
-
None
-
Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.)
-
None
Description
The latest version 2.7.3 of Xalan now tries to load the translet class right after generating it to prevent CVE-2022-34169 (integer truncation issue when processing malicious XSLT stylesheets). It does so using a simplistic ad hoc class loaded implemented as follows:
public class ByteArrayClassLoader extends ClassLoader {
byte[] ba;
public ByteArrayClassLoader(byte[] bArray) {
ba = bArray;
}
public Class findClass(String name) {
return defineClass(name, ba, 0, ba.length);
}
}
Note that it delegates to the default parent constructor ClassLoader() which in turn delegates to this(checkCreateClassLoader(), null, getSystemClassLoader()).
This works well as long as Xalan classes were loaded using the System Class Loader. However, if they were loaded differently, the class loading check fails due to the fact that org.apache.xalan.xsltc.runtime.AbstractTranslet the parent class of the generated translet cannot be found.
This is the case e.g. in during Quarkus build phase, where Quarkus Maven plugin sets up a custom class loader hierarchy for building the application.
Solution proposal
Making the ByteArrayClassLoader use the Current Thread Context Class Loader fixes the issue for us and I wonder whether that's a viable fix for the project maintainers?
public class ByteArrayClassLoader extends ClassLoader {
byte[] ba;
public ByteArrayClassLoader(byte[] bArray) {
super(Thread.currentThread().getContextClassLoader() != null ? Thread.currentThread().getContextClassLoader() : XSLTC.class.getClassLoader())
ba = bArray;
}
public Class findClass(String name) {
return defineClass(name, ba, 0, ba.length);
}
}
Attachments
Issue Links
- links to