You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by GitBox <gi...@apache.org> on 2022/10/18 09:53:50 UTC

[GitHub] [commons-jxpath] 0roman commented on pull request #25: Fix for Issue: CVE-2022-41852

0roman commented on PR #25:
URL: https://github.com/apache/commons-jxpath/pull/25#issuecomment-1282131075

   @bhmohanr-techie thanks for your effort, but we highly suggest to use the whitelist approach in https://github.com/apache/commons-jxpath/pull/26.
   
   The main problem is that the default behaviour of the library is not changing. That means if users will just update the jxpath jar file they'll still be vulnerable and they'll need to set a System property in addition.
   
   The next problem is that blacklisting individual components is not feasible for large projects. For example, if your project has 100 classes and you just want to allow access to one class you will need to set a system property for 99 classes e.g. `System.setProperty("jxpath.class.deny", "com.example1, com.example2, com.example1, ...");` From a security perspective, the feature in jxpath should rather be used to allow a small number of classes than to disallow a big number of classes.
   
   Furthermore, I have checked that "jxpath.class.deny=java.lang.Class" will not stop exploitation of [CVE-2022-41852](https://github.com/advisories/GHSA-wrx5-rp7m-mm49) as described by you, feel free to verify with xpath string "java.lang.Thread.sleep(1000000)".
   
   For those reasons, we think that the allowlist is the better approach to go forward. 


-- 
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: issues-unsubscribe@commons.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org