Log4J Complexities, Confusion, Search API and Apache Solr
The past week has been a dramatic one with the publication of a series of very serious Log4J issues. The severity of these issues should not be downplayed. Unavoidably, how these issues affect different products and how they can be mitigated has become clouded and unclear.
To examine the effect on Apache Solr, here are the key points from Apache Solr’s security page regarding the Log4J issue:
- Only Solr 7.4 and greater is affected.
- Solr 7.3 and older use a version of Log4J that is not vulnerable.
- Solr is not vulnerable to the followup Log4J issues: CVE-2021-45046 and CVE-2021-45105
- Passing system property log4j2.formatMsgNoLookups=true is suitable to mitigate (this is specific to Solr, and is not the case for other applications using Log4j)
The best course for mitigation is still to upgrade either Solr or the affected Log4j JAR files to the latest version. It is important, however, to continually analyze how these issues affect your specific installation. Environmental factors are not created equally and it is possible to be more or less at risk depending on the surrounding situation.
Solr 7.3 and older use Log4j 1.x, which is not affected by most of the Log4j issues.
See Log4j’s security announcements:
- CVE-2021-45105: “Log4j 1.x is not impacted by this vulnerability.”
- CVE-2021-45046: “Log4j 1.x is not impacted by this vulnerability.”
- CVE-2021-44228: “Log4j 1.x: “does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: Audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.” Apache Solr is not configured this way in default configurations.