[
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)
