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
