Update Lucene to avoid buffer overflow attacks

[inktomi]

Describe the bug The lucene-core package used today is vulnerable due to a Stack-based Buffer Overflow. The parseUnionExp(), parseInterExp(), and parseConcatExp() methods in the RegExp class do not properly handle recursion, leading to a Buffer Overflow when procession large inputs. This weakness could be exploited by a remote attacker by submitting a payload containing an excessively long string that causes excessive recursion, potentially leading to a Denial of Service (DoS) condition.

This is detailed in https://osv.dev/vulnerability/OSV-2023-705 and fixed in lucene by https://github.com/apache/lucene/pull/12462

Version of dependency-check used Gradle plugin 9.2.0

To Reproduce Include the plugin and run it in an environment that checks transitive dependencies for this issue. The dependency will be blocked.

Expected behavior The Dependency Check plugin does not use libraries that themselves have vulnerabilities.

[aikebah]

The risk is limited as the code is not using RegExp-queries towards Lucene

Upgrading the library would require dropping Java 8 support (Lucene 8.x has not been patched, Lucene 9 raises minimum Java runtime to 11)

@jeremylong Any objections on moving to Java 11 or later (so that we can upgrade to a patched version of Lucene)?

From the perspective of Maven builds I do not see an upgrade to require at least Java 11 runtime for the plugin execution as a blocker as other plugins have been starting to raise the required JDK level as well (e.g. SonarQube analyzer plugin that also requires maven to run on at least JDK 11; Maven itself is planning to raise the bar to Java 17 on the 4.x release (timeline unknown, beta release phase has started in May - https://maven.apache.org/docs/history.html))

[jeremylong]

This weakness could be exploited by a remote attacker by submitting a payload containing an excessively long string that causes excessive recursion, potentially leading to a Denial of Service (DoS) condition.

So a malicious actor is going to publish a library with the attack payload in the evidence we collect - that can result in a denial of service against a single node/agent in your CI or on your desktop. Mission impossible style attacks?

That being said - using this (and other CVEs as an excuse to upgrade) would be good. Let's put this on the list for the 11.0.0 release - with the other breaking change for the embedded h2 db.

[inktomi]

I totally agree it's not likely 😆 . I just wanted to report it since our system was flagging it and failing builds.

[jeremylong]

@aikebah for reasons - I may want to escalate the 11.0 release. We'll include the breaking change on the H2 database and upgrade to Java 11.

The main reason for wanting to do this soon is that we will also include https://github.com/jeremylong/Open-Vulnerability-Project/pull/183 - which will make it so the NVD can block clients that will not be able to parse the results. I'll release 10.0.2 in the morning (US Eastern). My hope is to have 11.0 released within a few days after that.

[jeremylong]

See the discussion here: https://github.com/jeremylong/Open-Vulnerability-Project/issues/184

[aikebah]

Sounds good to try and release soon indeed was planning to try and get this ticket done with up to an open PR this weekend, so that would fit fine.

[aikebah]

@jeremylong Any clue as to why the assumeFalse is coded at

https://github.com/jeremylong/DependencyCheck/blob/06e39fcd647dd2312283bd8d87198dbfc059d1be/core/src/test/java/org/owasp/dependencycheck/analyzer/ArchiveAnalyzerTest.java#L64

Java 11 no longer allows you to hack around in the accessibility of the Methods of java.lang.ClassLoader, but I fail to see why it should be ensured that the class has not yet been loaded. Maybe you can recall why it was coded like this. (similar holds for the more recent RpmExtension test, but that's likely a result of a copy/paste of the ZippableExtensions testcase to get started)

Edit: Need to slightly modify the remark Java 11 still allows it, but my local java was a few majors ahead and fully blocks it... still curious to know why that code is in

[aikebah]

@jeremylong Upgrading to Java 11 is likely going to be a bit more effort than initially expected... see #6809, which I'll work on to tackle first

[jeremylong]

I have absolutely no clue why the assumeFalse is there. It looks like it was added by @mbologna three years ago when the RPM analyzer was added. I'm okay removing it.

[jeremylong]

I ended up putting the updated OVC in 10.0.2 - and I am calling it a mandatory upgrade as the NVD may start blocking the older user-agent. See https://github.com/jeremylong/Open-Vulnerability-Project/issues/184