Hello,
I'm on the Apache Solr PMC, and I'm trying to do some due diligence on
understanding the extent to which "log4j2.formatMsgNoLookups" may or may
not be effective in mitigating certain vulnerabilities *for Solr*. Solr
recently upgraded to Log4j 2.16 but I want to validate the extent to which
this mitigation measure is appropriate for older versions of Solr. Log4j's
news page[1] has the following text:
*Older (discredited) mitigation measures*
>
> This page previously mentioned other mitigation measures, but we
> discovered that these measures only limit exposure while leaving some
> attack vectors open.
>
Other insufficient mitigation measures are: setting system property
> log4j2.formatMsgNoLookups or environment variable
> LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the
> logging configuration to disable message lookups with %m{nolookups},
> %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
>
> The reason these measures are insufficient is that, in addition to the
> Thread Context attack vector mentioned above, there are still code paths in
> Log4j where message lookups could occur: known examples are applications
> that use Logger.printf("%s", userInput), or applications that use a custom
> message factory, where the resulting messages do not implement
> StringBuilderFormattable. There may be other attack vectors.
>
[1]: https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
The use of the word "discredited" is suggestive that this
log4j2.formatMsgNoLookups setting will be of no use to anyone. My
suspicion is that it can be, but is dependent on the extent to which the
application (Solr + Slf4j) actually uses Log4j2. It is worth spending time
understanding this (instead of throwing up your hands and saying, just
upgrade) because upgrading is quite a hassle for many users. Many users of
Log4j only use Log4j via Slf4j which is comparatively easier to audit.
Solr is not quite in this camp; it injects a custom appender in order to
render messages on it's logging UI.
Taking a specific example here given in the news page: Logger.printf. I'm
not seeing the problem; can someone offer me a pointer? I've checked out a
version of Solr that uses Log4j 2.14.1 and set the system property, and
crafted up some trivial unit test that calls Logger.printf with the intent
of exploring what happens internally that is concerning. I do see the
problem in MessagePatternConverter that is averted by the system property.
Feel free to reach me directly if there are sensitivities to a response.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
