All,
If you are running DSpace 6.x or below, you are not be impacted by this vulnerability, as DSpace 6.x and below still rely on log4j v1 (and they don't use the JMS Appender which is where the vulnerability can be exploited with log4j v1).
If you are running DSpace 7.x, YOU MAY BE IMPACTED. A few possible known quick fixes are available.
-
(Code level fix) In the source code of the DSpace backend (REST API), update the <log4j.version> tag in your [src]/pom.xml to say "2.15.0". Rebuild the backend (mvn clean package) & redeploy (ant update) and restart Tomcat. You are now on a protected version
of log4j v2. (This fix will also be provided in the upcoming DSpace 7.2 release in Feb, 2022.)
-
(Java upgrade) Ensure you are running the latest version of the JDK (Java).
It is reported that JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by this vulnerability. So, if you are already running a JDK later than those versions, you may need to do nothing.
- (Configuration fix workaround) If neither of the above are easily possible, you can temporarily update your [dspace]/config/log4j2.xml and [dspace]/config/log4j2-console.xml,
replacing any "%m" patterns with "%m{nolookups}"
(per
temporary mitigation suggestion). Then restart Tomcat. These %m patterns can be found in 3 places total in our log4j2 configs:
We'd highly recommend taking one of the following steps
immediately if you are running DSpace 7.x in Production.
If you have additional questions, feel free to email secu...@dspace.org (which emails all DSpace Committers). If you have a public suggestion,
feel free to send it to this list to help other DSpace users who may be impacted.
Tim