This is a great question, and something I'm working on documenting today.
The relevant change in 2.17.0 is
https://github.com/apache/logging-log4j2/commit/806023265f8c905b2dd1d81fd2458f64b2ea0b5e
Outside of evaluating the configuration itself, we no longer recursively
evaluate substitution results. This means that
config.getStrSubstitutor().replace(event, "${event:Message}") for the event
'log.info("Hello, ${lower:WORLD}")' will evaluate to the literal string "Hello,
${lower:WORLD}" where previous releases would incorrectly evaluate to "Hello,
world". I would certainly recommend writing unit tests in your project to
verify this behavior as well :-)
-ck
On Wed, Dec 22, 2021, at 11:29, Franz van Betteraey wrote:
> Sorry Gary for not being precise enough. Yes, I am using the latest
> patched version 2.17.0 and hope to benefit from the security patches.
>
> My custom layout class extends AbstractStringLayout and the
> configuration is injected via the @PluginConfiguration parameter of the
> PluginFactory method.
>
> @PluginFactory
> public static MyCustomLayout createLayout(
> @PluginConfiguration final Configuration config, ...)
>
> I than get the StrSubstitutor from config.getStrSubstitutor(). My custom
> layout allows to specify/configure a list of lookups like
> "${event.ThreadName}" or "${date:yyyy-MM-dd'T'HH:mm:ss.SSSZ}" and
> resolves these (one by one) via 'strSubstitutor.replace'.
>
> I do not call this method on "${event:Message}" placeholder. Here I just
> use 'logEvent.getMessage().getFormattedMessage()' to get the message text.
>
> All lookup placeholder are specified via configuration (thus in my hand).
>
> My hope now is that the implemented security patches (disabled Jndi
> Appender, substitution recursion, etc.) will also be effective in this
> case of use.
>
> Am 22.12.2021 um 13:45 schrieb Gary Gregory:
> > Since you don't specify which version you are using I will assume that you
> > are using our latest patched version which is 2.17.0, the best and safest
> > choice.
> >
> > Your description is also too vague: The
> > method StrSubstitutor.replace(LogEvent, String) is an instance method and
> > you do not describe how you created the StrSubstitutor, so there is no way
> > for me to tell what is safe and what is not
> >
> > Gary
> >
> >
> > On Wed, Dec 22, 2021 at 5:25 AM Franz van Betteraey <fr...@van-betteraey.de>
> > wrote:
> >
> >> Dear Log4j Team,
> >>
> >> first of all thank you for your tireless efforts around the project,
> >> which I appreciate very much.
> >>
> >> My question is: Is it safe to call 'StrSubstitutor.replace(final
> >> LogEvent event, final String source)' in a custom Layout class that
> >> inherits from AbstractStringLayout? The StrSubstitutor object is derived
> >> via the configuration and the 'source' string might contain any lookup
> >> placeholder.
> >>
> >> It is not clear to me if the defense mechanisms against the current
> >> security vulnerabilities take effect before such a call and prevents the
> >> framework on calling this method, or if the call is still secure and the
> >> defense happens afterwards (e.g. by not instantiating lookups).
> >>
> >> I thank you for any advice and wish you happy and peaceful holidays.
> >>
> >> Franz
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>
