Hello Andy, I hate to be the bearer of bad news, but in a recent discussion on Lobsters [1] it was brought to my attention that there apparently exists a bypass [2] of the fix in 2.15.0 that brings back the RCE. To be clear, the new exploit no longer requires fiddling with the Thread Context Map settings. The CVE page [3] now says "This vulnerability has been modified since it was last analyzed by the NVD. It is awaiting reanalysis which may result in further changes to the information provided.", which means that the original score 3.7/10 no longer applies to the new CVE.
Harri, the WAR file of the 4.3.1 was missing log4j JARs and I had success simply placing 2.16.0 JARs myself. You should be able to use that as a temporary mitigation until the new version comes out. /Andrew [1]: https://lobste.rs/s/ccc9tu/patch_fixing_critical_log4j_0_day_has_its#c_c2syst [2]: https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/#update-the-localhost-bypass-was-discovered [3]: https://nvd.nist.gov/vuln/detail/CVE-2021-45046 On 2021-12-15, 15:36, "Andy Seaborne" <a...@apache.org> wrote: On 15/12/2021 13:44, Harri Kiiskinen wrote: > Hi, See https://blogs.apache.org/security/ > > it is possible that our university IT service may yet choose to be > strict about this and require 2.16.0 from all services open to public, The PMC are all volunteers. This CVE hasn't been scored by NVD yet. This CVE requires local access to enable features. Many systems use log4j1 that has CVE-2019-17571 (in a component that isn't necessarily used). Log4j 1.x is EOL since 2015. When Jackson JSON has a serious flaws a few years ago, it was followed by a number of CVEs as people looked hard at it. > which would be bothersome four our projects in case Jena stays with > 2.15.0. I guess similar situations might exist elsewhere; but perhaps > this is not a question of days, as it was with the previous CVE, since > this is not quite as severe. Fuseki uses log4j in default configuration. See the CVE details. > My point: I may need to be able to show Jena is using 2.16.0 to be able > to run our servers at some point. JENA-2214 - already done. The Apache Foundation produces source code. Security is one of the reasons for this. Binaries are a convenience. Take the Jena source release, change the log4j version in the top POM. Build. Andy > > Best, > > Harri Kiiskinen > > > > On 15.12.2021 12.23, Andy Seaborne wrote: >> On 14/12/2021 20:51, Brandon Sara wrote: >>> Should we expect another release (like version 4.3.2) given Log4J >>> updating to 2.16.0 in response to this other CVE: >>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-45046? >> >> Going to the link to the log4j security page, the log4j team rates it >> as "moderate" and says it's denial-of-service attack, not code >> injection unlike 44228. >> >> Fuseki uses log4j in default configuration. >> Fuseki uses logging via slf4j. >> Fuseki does not use log4j ThreadContext. >> Fuseki does not use %X, %mdc, or %MDC. >> >> The Fuseki logging built-in and default pattern uses plain %m in the >> pattern: >> >> [%d{yyyy-MM-dd HH:mm:ss}] %-10c{1} %-5p %m%n >> >> although the user can change the log4j2 configuration to be a >> non-default configurations and also set their own logging pattern >> locally. that's outside the distributed Fuseki binaries. >> >> Personal opinion: I don't see a need for 4.3.2. >> >> Andy > >
