javasolrlog4j

Upgrade Apache Solr 8.10.1 log4j 2.14.1 version to 2.15 to address critical vulnerability


Recently a critical log4j vulnerability was discovered.

I want to upgrade the log4j as used by my current Solr instance, so I checked here. However, I don't see a log4j.properties file in "/server/resources/" folder. All I see there is:

None of these files contain a version. So to upgrade, is it safe to download the latest version of log4j and overwrite the existing jars in folder "\solr-8.10.1\server\lib\ext", or what are the recommended steps to upgrade?


Solution

  • The link you're pointing to is for an older version of Solr (6.6 instead of 8.10.1). The correct version is https://solr.apache.org/guide/8_10/configuring-logging.html where it mentions using log4j 2.

    The file log4j2.xml (and even `log4j.properties for that matter) configure the logging itself, not the version of log4j. So updating that file is irrelevant.

    Here's what the project page recommends:

    2021-12-10, Apache Solr affected by Apache Log4J CVE-2021-44228

    ...

    Description: Apache Solr releases prior to 8.11.1 were using a bundled version of the Apache Log4J library vulnerable to RCE. For full impact and additional detail consult the Log4J security page.

    ...

    Mitigation: Any of the following are enough to prevent this vulnerability for Solr servers:

    • Upgrade to Solr 8.11.1 or greater (when available), which will include an updated version of the log4j2 dependency.
    • Manually update the version of log4j2 on your runtime classpath and restart your Solr application.
    • (Linux/MacOS) Edit your solr.in.sh file to include: SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
    • (Windows) Edit your solr.in.cmd file to include: set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
    • Follow any of the other mitgations listed at https://logging.apache.org/log4j/2.x/security.html

    What you're proposing (overwrite the existing jars in folder "\solr-8.10.1\server\lib\ext") seems like the second approach, so it should probably work fine. Just make sure this is the correct place that contains the log4j dependency.