[jira] [Created] (XALANJ-2664) The new class loading check in 2.7.3 does not work if Xalan was not loaded using System Class Loader

["Peter Palaga (Jira)" <ji...@apache.org>]

Peter Palaga created XALANJ-2664:
------------------------------------

             Summary: The new class loading check in 2.7.3 does not work if Xalan was not loaded using System Class Loader
                 Key: XALANJ-2664
                 URL: https://issues.apache.org/jira/browse/XALANJ-2664
             Project: XalanJ2
          Issue Type: Bug
      Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects.  Anybody can view the issue.)
          Components: Xalan
    Affects Versions: 2.7.3
            Reporter: Peter Palaga
            Assignee: Gary D. Gregory


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:

{code}
    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);
        }

    }
{code}

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.

h3. 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?

{code}
    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);
        }

    }
{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org
For additional commands, e-mail: dev-help@xalan.apache.org