Upgrade the version of commons-configuration

[smmsit]

Hi,

I'm getting code violation in mend report for my project that the version of commons-configuration being used is very old.
commons-configuration has been relocated to commons-configuration2
Upgrading the version of commons-configuration from 1.10 to 2.11.0 will fix this issue
Is there any plan to upgrade it?

[kwwall]

Our core team discussed this previously in a private email a while back. The bottom line is that continuing to use Apache Commons Configuration 1.10 posed no risk to those using ESAPI as (at the time) there was known unpatched vulnerabilities affecting that version of the library. Furthermore, upgrading to the latest 2.x version (which has a rockier vulnerability than the 1.x versions; e.g., see https://www.cvedetails.com/version-list/45/88810/1/Apache-Commons-Configuration.html) just to make some arbitrary SCA tools to stop squawking is not a compelling reason for us to upgrade. Moving from major release # to another is rarely easy. However, in this case, this is (only) used in complicated feature (AccessController) that is rarely by any ESAPI clients and that no one on the core team has much deep understanding of? Why is that a problem? Because, IIRC, the JUnit tests for that, especially with respect to the ESAPI-AccessControlPolicy.xml policy file, are only used by the classes:

• src/main/java/org/owasp/esapi/reference/accesscontrol/policyloader/ACRPolicyFileLoader.java
• src/main/java/org/owasp/esapi/reference/accesscontrol/policyloader/ACRParameterLoaderHelper.java
• src/main/java/org/owasp/esapi/reference/accesscontrol/policyloader/ACRParameterLoader.java
• src/main/java/org/owasp/esapi/reference/accesscontrol/policyloader/DynaBeanACRParameterLoader.java

are all very minimal. Therefore we are are concerned that changing from Commons Configuration 1.10 to the latest 2.x release could very well break something that some client is using. (While we know that the number of ESAPI clients using AccessController is small, we do not know if it is zero. It might not be, especially in some customized contract work that was done using ESAPI in its early years.)

Neither do I see any official announcement by Apache that Commons Configuration 1.10 has been officially declared end-of-service. We likely would consider that as a compelling reason to move to the latest 2.x release. But, depending the anticipated effort of doing so, we instead might just decide to officially deprecate org.owasp.esapi.AccessController and make the issue disappear that way. (Although that approach would be a process that takes a year or more).

However, I think that you likely are putting too much faith in your SCA tool. I monitor vulnerable dependencies in ESAPI via GitHub Advanced Security Dependabot, Synk SCA, and the OG, OWASP Dependency-Check.

Note that by default, OWASP Dependency-Check does report 2 CVEs for Commons Configuration 1.10. Specifically, CVE-2024-29131 and CVE-2024-29133. However according to the Dependency Check GitHub Issue 6704, these are both false positives, as these both are only applicable to the 2.x releases of Commons Configuration. As a result, we have suppressed them. If Mend SCA flagged either of these 2 CVEs, it is likely making the same mistake.

At any rate, you have not made a compelling case for the ESAPI team to take any action. Perhaps instead, you should simple do a deep-dive examination on your end of your Mend SCA report results and ensure that there is an exploitable path. If there is, report it to us (ideally, via the official means of "reporting a vulnerability"). Alternately, you could simply set the value of your ESAPI.properties file for the property ESAPI.AccessControl to the name of some non-existent fully-qualified-classname (e.g., "com.yourcompany.NoSuchClass") and then if you were to accidentally call ESAPI.accessController() you would get an exception before there was any opportunity for anyone to exploit any vulnerability in Apache Commons Configuration 1.10 via ESAPI. Still another option is to have your build file (pom.xml, build.gradle, etc.) exclude the trahsitive dependency, commons-configuration:commons-configuration:1.10 and to instead use org.apache.commons:commons-configuration2:2.11.0. (That should work fine if aren't using ESAPI's AccessController interface.

Just so you know, contrary to popular opinion of SCA tool vendors, that absence of activity on a given branch does not necessarily mean that that branch is past end-of-life or no longer supported. SCA tools generally don't concern themselves with false positives either. I will give you an opportunity to reply and make a compelling case, but this is not something that we are likely to spend some time fixing. (If it weren't for scarce JUnit tests for this, I would just suggested to you to just make a PR for this, but given that that likely would be a substantial effort on your part I didn't wish to mislead you with regards to effort. I doubt you want to take that path; however, if that interests you, let's discuss it here.) But the core ESAPI team's opinion likely will be we see not reason to address this just to get a single SCA tool to stop squawking. To us, that would be setting a very poor precedent.

[picsouds]

@kwwall, i agree with you, however I pushed a pull request with org.apache.commons:commons-configuration2 which maintains compatibility especially for ACRParameterLoaderHelper.

[in-fke]

Maybe such a low-level lib should not depend on commons-configuration at all (neither commons-configuration nor commons-configuration2). Or it should contain optional depependencies to provide load mechanisms that can be chosen / externalized.

[jeremiahjstacey]

@in-fke Thanks for the input. The next time the project undergoes a major refactor we'll be sure to consider it. Until then, maven provides the ability to exclude transitive dependencies from projects. As long as you're not leveraging the classes in the ACR components that Kevin outlined above, there should be no harm in using maven to optionally exclude that transitive dependency in your project.
https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

At that point where you know you're not using the ACR classes it would seem like an exercise simply to change a number in a report. Identifying content as a "non-executable path" has always been a good conversation in my experience, and often results in a better shared understanding of a baseline, with no additional modifications or effort required.