2.5.4.0 and CVE-2024-29131, 33.

[kumakaori]

As @kwwall states in the Announcement #841, I agree that the GHSAs are scoped only to 2.0+ and 1.10 is a mis-hit.
However... some Vendors will do additional investigation, and saddle Enterprises with Knowledge:

[Vendor] team discovered that [CVE-2024-29131] was also introduced in version 1.8 of the predecessor package commons-configuration instead of only affecting versions from 2.0 before 2.10.1 as stated in the advisory.

[Vendor] team discovered that [CVE-2024-29133] was actually introduced in version 1.0-rc1 of the commons-configuration package instead of the version 2.0.0 of the commons-configuration2 package as stated in the advisory.

It wouldn't surprise me if the above data is related to why OSS Index is marking 1.10 as vulnerable.

The only part of ESAPI that uses Apache Commons Configuration is [if] you are using ESAPI's AccessController and in 15 years that I have been working on ESAPI, I have yet to run across one place where that is used.

Unfortunately, many Enterprises are too rigid to accept "Not using vulnerable component" as valid reasoning for negating a vulnerability in a dependency. Their only option is to have a non-vulnerable version.

Based on this information, and building on what's been written at #748, is this a tipping point where ESAPI will consider updating to org.apache.commons : commons-configuration2 : 2.10.1?.

(Apologies if this should've been a comment on the Announcement. Other announcements did not seem to have similar discussions opened, so chose to raise this instead. Closest similar discussions have been #748, and somewhat #671 for 'how ESAPI handles dependencies'.)

[kwwall]

@kumakaori wrote:

Unfortunately, many Enterprises are too rigid to accept "Not using vulnerable component" as valid reasoning for negating a vulnerability in a dependency. Their only option is to have a non-vulnerable version.

Which is insane because:

1. Most of the SCA findings are usually not exploitable in any given application.
2. Even for the ones that have an exploitable path in your code, most of them you either have to:

• wait for a patch to become available
• fork the code and patch it yourself
• try to exclude a transitive dependency and then directly include an available patched version and hope for the best

That's one reason why I try to write up detailed Security Bulletins and describe the analysis when ESAPI is or is not affected by some CVE and, when possible, describe workarounds.

Unfortunately, I think a lot of this mentality is caused by well-intentioned Vulnerability Management people who mistakenly belief that application patching should be approached in the same manner that OS patching is done. That was a large part of my (shameless plug) OWASP Global AppSec DC 2023 talk, "From SBOMs to F-Bombs: Vulnerability Analysis, SCA Tools, & False Positives & Negatives". (Because they did not show the screen, the slides are at https://static.sched.com/hosted_files/owasp2023globalappsecwashin/e9/kwwall_notes-OWASP-2023-SBOMs_to_F-Bombs.pdf.

[kwwall]

@kumakaori wrote:

However... some Vendors will do additional investigation, and saddle Enterprises with Knowledge:
and
It wouldn't surprise me if the above data is related to why OSS Index is marking 1.10 as vulnerable.

It wouldn't surprise me either, but I for one don't place much faith in their private vulnerability DB findings. I actually called on this same vendor on this at that same talk, although to save OWASP embarrassment (in case they were a sponsor of Global AppSec),I didn't call them out by name. But it was them. It's all there in the PDF of my slide deck, complete with speakers notes.

As a security practitioner who's been doing vulnerability analysis of Java libraries since the early 2000s, if you want to make a claim that something is vulnerable, you either better be able to point me to the flawed code or some me a working PoC exploit. Seriously the whole application patch management ecosystem is one hot mess right now and the commercial SCA vendors are not helping. In fact, I might go as far as saying they are making it worse.

[kwwall]

@kumakaori asked:

Based on this information, and building on what's been written at #748, is this a tipping point where ESAPI will consider updating to org.apache.commons : commons-configuration2 : 2.10.1?

I started down that path the evening of Wed, 5/29, when I first ran Dependency Check and saw that it reported those 2 CVEs. I figured it would be faster to just patch it than to do a full-deep dive analysis to see if they were truly false positives as I expected. It was easy enough to get ESAPI to compile the AccessController using org.apache.commons : commons-configuration2 : 2.10.1, but getting the regression tests to pass was an ordeal. It was bad enough that I felt like I was coming down with the flu, but I really wanted to get the release out on the 29th, especially since I had promised it for the 28th and then came down with a bad migraine that night. Since I thought the 2 reported CVEs were likely FPs, I made a call to do a release, and then, if need be, a subsequent patch.

Now, does that me that I'm going to patch this regardless? Well, I will if either:

• Someone can convince me that at least 2 of those 2 reported CVEs are true positives.
• Someone else does makes the code changes and submits it via a PR.

However, the core team really wants to move on and get started with ESAPI 3.x. I haven't thought about it much for a year for many reasons that I won't bore you with, but it's become clear that because all 3 of the ESAPI core development team have full time jobs and family obligations, it's difficult for us to split our time across ESAPI 2.x and 3.0. We'd like to move on from 2.x, but we feel an obligation to support the ESAPI community. So what we really need is either more volunteers to help out with the general 2.x maintenance or someone to financially sponsors one or more of us so we can quit our day jobs and work on ESAPI full time. (And talking to the ZAP core development team, I don't think either of those things are very likely.)

So, if you or @Rockefeller think this sort of patching to new major versions of libraries is important even when the old versions have no known vulnerabilities, step up and volunteer to help us. We would welcome the assistance.

P.S.- Thanks for your thoughtful input.

[kwwall]

So, sadly, this seems to have not been a FP. I did research over the weekend and ran across this:

• https://issues.apache.org/jira/browse/CONFIGURATION-840

So I took that, hacked it up and came up with PoC with nothing more than a few POM tweaks to get it to use commons-configuration:comoms-configuration:1.10 and compile it using JDK 11. So this definitely affects Apache Commons Configuration 1.10 as well. ESAPI will be planning a switch to use 2.10.1, although for reasons I am not going to go into now because of the late hour, I am very confident that there is not exploitable path in ESAPI itself.

[kwwall]

If anyone wants the POC for 1.10, drop a comment here. I need to convert it from a .tgz to .zip file and I am dead tired. Later.