Excellent write up! Gary
On Thu, Dec 23, 2021, 10:19 Carter Kozak <cko...@ckozak.net> 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 < > 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 > > > > > > > > > > -ck >
