Thanks so much for responding to me Ralph! (and promptly)
I think this is really useful information that you shared that would be a
relief to many users. Users that only use Log4j2 via Slf4j are mitigated
by this technique. That's a big deal! Most other users using Log4j2
directly would as well, I think. The wording of a "discredited" mitigation
is not a word I would have used.
I audited Message implementations that don't implement
StringBuilderFormattable, thus those that could get around this system
property mitigation:
* RenderedMessage & LocalizedMessage: used in "log4j-1.2-api" -- a legacy
bridge from Log4j 1.2.
* StatusMessage: This is for debugging Log4j2 internally? Thus as long as
log4j itself wouldn't log user input (not plausible to me), we should be
safe.
* MessageFormatMessage: Used "log4j-jul" module -- thus users using Log4j
2.x API but want to log to JUL. Anyway, it doesn't matter since the
vulnerability risk is in log4j-core which wouldn't be used in this scenario.
* ObjectArrayMessage: Only used in tests. Appears to be leftover tech-debt
from some previous time when there was a CSV layout.
* FlowMessage: Appears used for trace logging method entry/exit. I
suppose someone configuring logging could enable this, and if it were done
on a method with user input, then there is a risk. Right?
* FormattedMessage: Not used except for indirectly via LocalizedMessage
referenced above.
* StringFormattedMessage:
* Used in Logger.printf(). (not used by Slf4j)
* Used in LogManager.getFormattedLogger. (not used by Slf4j)
And one or two more are only used in log4j-perf.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Dec 21, 2021 at 9:40 AM Ralph Goers <ralph.go...@dslextreme.com>
wrote:
> 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
>
>
