bhmohanr-techie opened a new pull request, #25:
URL: https://github.com/apache/commons-jxpath/pull/25
# Issue ID:
CVE-2022-41852
# Issue Description:
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.
# CVSS Version 3.x:
9.8 Critical
# Affected versions:
1.3 and earlier
# Vulnerability Type:
Remote Code Execution (RCE)
# 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());
# Workarounds:
- No workaround available
# 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.
# 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.
# 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, we need to configure
"jxpath.class.deny=java.lang.Class" which will ensure that Class.forName() call
is blocked when passed via xpath strings.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]