Re: is it save to call StrSubstitutor.replace(final LogEvent event, final, String source) with Log4j 2.17.0

Thanks Franz! All the best for 2022.

Gary

On Thu, Dec 30, 2021, 09:17 Franz van Betteraey <[email protected]>
wrote:

> Dear David, Gary and especially Carter,
>
> Thank you for taking the time to answer my question about the
> StrSubstitutor. I finally had time to look at the tips today and they
> were very helpful.
>
> I wish you - and the whole log4j team - a good start into 2022 and a
> great year.
>
>    - Franz
>
> Am 23.12.2021 um 21:56 schrieb Gary Gregory:
> > Excellent write up!
> >
> > Gary
> >
> > On Thu, Dec 23, 2021, 10:19 Carter Kozak <[email protected]> wrote:
> >
> >> I've put together a more thorough document here:
> >>
> >>
> https://github.com/apache/logging-log4j2/blob/release-2.x/docs/2.17.0-interpolation.md
> >>
> >> On Wed, Dec 22, 2021, at 11:38, Carter Kozak wrote:
> >>> 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 <
> >> [email protected]>
> >>>>> 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: [email protected]
> >>>>>> For additional commands, e-mail: [email protected]
> >>>>>>
> >>>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [email protected]
> >>>> For additional commands, e-mail: [email protected]
> >>>>
> >>>>
> >> -ck
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>