[jira] [Resolved] (JXPATH-201) CVE-2022-41852 RCE vulnerability in JXPathContext class functions

["Bharath Mohanraj (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JXPATH-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bharath Mohanraj resolved JXPATH-201.
-------------------------------------
    Resolution: Fixed

h1. Pull Request:

https://github.com/apache/commons-jxpath/pull/25
h1. Fix:

Please note that, the fix added here is via a new system property (enabling this property, will address the issue). This will ensure that we are not breaking functionality for existing users.
 * In order to fix this issue, a filter class "JXPathFilter.java" is added in JXPath. This filter object will be used to validate if the xpath passed to JXPath is a valid one
 * This new filter class, for now implements JXPathClassFilter interface, which is used to check the java classes passed in xpath. In future, we could implement any other interface, to verify other cases as well.
 * In this filter, the class filter validates to see if the class being loaded in JXPath is part of the restriction list. The restriction can be configured via a system property "jxpath.class.deny"
 * System property "jxpath.class.deny" can be set to specify the list of restricted classnames. This property takes a list of java classnames (use comma as separator to specify more than one class). If this property is not set, it exposes any java class to javascript Example: jxpath.class.deny=java.lang.Runtime will deny exposing java.lang.Runtime class via xpath, while all other classes will be exposed.
 * When a new extension function is created by JXPath, it uses the filter to check if the xpath supplied is a valid string, only then function instances are created.
 * The changes are added to pass JXPathFilter instance as an additional argument to the methods that create the ExtensionFunction objects. In addition, the ClassLoaderUtil class is modified to use the JXPathFilter instance when a new Class instance is created. Please note that, the changes here are added as overloaded methods, so that we are not affecting existing code for anyone.

h1. Unit Testing:
 * Verified that the RCE vulnerability is no more applicable for any of the functions in the JXPathContext class.
 * Verified different code areas and found that the fix is addressed in all cases. Testing covers Class Functions, Package Funcions, Function Libraries and functions exposed in JXPathContext.
 * All the test cases for this change is covered in unit test code: in ExtensionFunctionTest.java. 10 new test methods are added in this class, to make sure all possible areas are covered.

h1. Summary:
 * The changes added in the pull request, takes effect only if the newly added System property "jxpath.class.deny" is set. This ensures that existing users of jxpath are not affected by this change.
 * The new system property can be configured based on the environment and user needs.
 * In order to fix [CVE-2022-41852|https://github.com/advisories/GHSA-wrx5-rp7m-mm49], we need to configure "jxpath.class.deny=java.lang.Class" which will ensure that Class.forName() call is blocked when passed via xpath strings.

> CVE-2022-41852 RCE vulnerability in JXPathContext class functions
> -----------------------------------------------------------------
>
>                 Key: JXPATH-201
>                 URL: https://issues.apache.org/jira/browse/JXPATH-201
>             Project: Commons JXPath
>          Issue Type: Bug
>    Affects Versions: 1.3
>         Environment: Steps to Reproduce:
> - Issue reported here is, all functions in the class JXPathContext (except compile and compilePath) are vulnerable to a remote code execution attack. - An arbitrary code can be injected in the xpath values passed to these functions, and it allows triggering java classes that can exploit the target machine.
> - For instance, the iterate() method in the JXPathContext class, can be invoked by passing the xpath argument value as, java.lang.Thread.sleep(9999999) or java.lang.Class.forName("ExploitTest"). These examples can result in triggering the injected java code, and can exploit the target machine.
> - Example: 
>       JXPathContext context = JXPathContext.newContext(new Test() ); 
>       Iterator result = context.iterate("java.lang.Thread.sleep(9999999)"); 
>       System.out.println("result.hasNext() - " + result.hasNext());
>            Reporter: Bharath Mohanraj
>            Priority: Critical
>
> Those using JXPath to interpret untrusted XPath expressions may be vulnerable to a remote code execution attack. All JXPathContext class functions processing a XPath string are vulnerable except compile() and compilePath() function. The XPath expression can be used by an attacker to load any Java class from the classpath resulting in code execution.



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