The system property blocked lookups from being processed in what I would
call “normal” logging - those using the style logger.info(“Hello {}”, name).
However,
if you made a call like logger.printf(“Hello %s”, name) lookups would not be
blocked.
If you obtained your logger with a special LoggerFactory such as
Logger logger = LogManager.getLogger(name, new MessageFormatMessageFactory());
Then in all likelihood the resulting logging calls would not have lookups
blocked.
So if you know that you only log using ParameterizedMessage (the kind with {})
then using the system property would work.
The problem is that the property is only blocking Messages that implement
StringBuilderFormattable. ParameterizedLayout does while the printf method
uses StringFormattedMessage which does not implement that interface.
Ralph
> On Dec 21, 2021, at 6:23 AM, David Smiley <dsmi...@apache.org> wrote:
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
