FAQ: DSpace & log4j critical vulnerabilities (CVE-2021-44228 and CVE-2019-17571)

[Tim Donohue]

All,

We know it's been a crazy week for those tracking down which systems are vulnerable to recent log4j vulnerabilities.

As these questions continue to come up, here's a quick guide based on what we know today.

Is DSpace vulnerable to CVE-2021-44228 (aka Log4Shell) in log4j v2?

https://nvd.nist.gov/vuln/detail/CVE-2021-44228 (critical vulnerability)

• DSpace 7.0 & 7.1 are both vulnerable.  Upgrade as soon as possible to 7.1.1 (or above) or patch your system. You also must upgrade/patch your Apache Solr. See 7.1.1 Release Notes for information: https://wiki.lyrasis.org/display/DSDOC7x/Release+Notes#ReleaseNotes-7.1.1ReleaseNotes(BackendOnly)
• DSpace 6.x, 5.x or 4.x (or below) are *not vulnerable*, as they all use log4j v1 exclusively with a default configuration which is not impacted. (At this time there is no way to upgrade these older DSpace releases to log4j v2. See below for more info.)

(Obviously, as this vulnerability is so new, it's possible there will be updates. We are closely watching everything coming out of the log4j community to ensure the DSpace can be updated as needed.)

Is DSpace vulnerable to CVE-2019-17571 critical vulnerability in log4j v1?

https://nvd.nist.gov/vuln/detail/CVE-2019-17571 (critical vulnerability)

• DSpace 7.x releases are *not vulnerable* as they use log4j v2.
• DSpace 6.x, 5.x or 4.x (or below) are also *not vulnerable* (out of the box). DSpace's default log4j v1 configuration does NOT use the vulnerable SocketServer/SocketAppender configuration. Instead, we exclusively use FileAppenders, see for example: https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/log4j.properties#L46 
• HOWEVER, if you've highly customized your DSpace log4j v1 configuration, you should double check you are not using SocketAppenders. A vulnerable SocketServer/SocketAppender configuration would look like this: https://howtodoinjava.com/log4j/log4j-socketappender-and-socket-server-example/

Can DSpace 6.x, 5.x or 4.x be upgraded to log4j v2?  log4j v1 is EOL.

Unfortunately, log4j v2 is not backwards compatible with log4j v1. Therefore, this is not a simple upgrade (e.g. it took over 1,000 lines of code changes to update DSpace 7.x to log4j v2, see PR 2241).  This upgrade would likely be more complex​ in DSpace 6.x/5.x/4.x, as those releases also used older versions of Apache Solr (and other dependencies) which relied on log4j v1 as well.

Overall, if you need to use log4j v2 more immediately, we'd recommend upgrading to DSpace 7.x.  It's unlikely that earlier releases will ever support log4j v2. (All that said, if anyone does find a way to upgrade earlier versions of DSpace to log4j v2, we'll be sure to let everyone know.)

If there are other questions, feel free to ask them on this list, or email secu...@dspace.org.

Tim 

--

Tim Donohue

Technical Lead, DSpace

tim.d...@lyrasis.org

Lyrasis.org | DSpace.org

[Paul Kobasa]

Hi Tech support,

I'm using Dspace 6.3 on Centos 7. My Cyber Security colleagues tell me that there are 3 other vulnerabilities in our installation:

CVE-2022-23302,  CVE-2022-23305, and  CVE-2022-23307

I've not been able to verify log4j 1.x, as it is used in dspace V6.3 is configured in such a way that these vulnerabilities are exploitable. 

Please could you confirm if Dspace 6.3 is not affected by these?

Thanks,

Paul.

[Tim Donohue]

Hi Paul & all,

Based on a quick reading of those vulnerabilities, those 3 vulnerabilities would only affect your DSpace site if you have modified the default log4j v1 configuration of DSpace 6.x (or below).

CVE-2022-23302 - Says it only impacts log4j v1 when log4j is configured to use JMSSink.  DSpace's out of the box configs do not use JMSSink by default. That'd only impact you if you are using a JMSAppender (DSpace only uses FileAppenders and ConsoleAppenders by default).

CVE-2022-23305 - Says it only impacts log4j v1 when log4j is configured to use a JDBCAppender.  Again, DSpace doesn't use this configuration of log4j by default.

CVE-2022-23307 - Says it's related to an older Apache Chainsaw vulnerability https://nvd.nist.gov/vuln/detail/CVE-2020-9493 .  According to that old issue, the vulnerability requires "configuring Chainsaw to read serialized log events".  Chainsaw is a graphical user interface for analyzing log files, and DSpace doesn't use or configure this by default. My understanding is that setting up Chainsaw would require additional configuration in your log4j configs: https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/chainsaw/package-summary.html

So, at least based on a quick analysis, I don't believe the out-of-the-box DSpace 6.x (or below) log4j v1 configuration is vulnerable to any of these issues.  That said, if you modify DSpace 6.x's default log4j v1 configuration (https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/log4j.properties) to use a different Appender type or to enable Chainsaw, then you *would be vulnerable*.  If anyone finds I've overlooked anything in this analysis, please do let us know.

If you still want to get off of log4j v1 regardless, you have a few options:

1. Upgrade to DSpace 7, which uses the latest log4j v2.

2. Consider installing this "work in progress" PR for DSpace 6.x, which replaces log4j with the reload4j project: https://github.com/DSpace/DSpace/pull/8144  The reload4j project (https://reload4j.qos.ch/) provides some ongoing patching of log4j v1, since log4j v1 is now considered EOL and is not maintained by Apache. This PR has not yet been merged into DSpace 6.x, but it is undergoing testing. If you decide to test this, please let us know your results by commenting on the PR itself.

Sincerely,

Tim Donohue