[
https://issues.apache.org/jira/browse/LOG4J2-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376998#comment-15376998
]
Joern Huxhorn commented on LOG4J2-1226:
---------------------------------------
There's another big problem with live objects in log messages, by the way.
If the appenders are working asynchronously from the thread that emitted the
message then that thread can potentially change the object contained in the
message before the message is actually processed by the appender.
Logback is handling this problem in its
{{ILoggingEvent.prepareForDeferredProcessing()}} method. There is simply no way
you can guarantee that the above scenario won't happen in a language like Java
if you don't transfer live objects into an immutable representation, i.e. a
String.
Using live objects (vs. String representation) works fine for synchronous
appenders but introduces "lying" log output for asynchronous ones.
This is an entirely different issue with much broader implications but I
mention it here anyway since fixing that issue would also fix this issue
passively. (Assuming that {{Throwable}} is also replaced by a
{{ThrowableProxy}}).
> Message instances are simply serialized. They mustn't.
> ------------------------------------------------------
>
> Key: LOG4J2-1226
> URL: https://issues.apache.org/jira/browse/LOG4J2-1226
> Project: Log4j 2
> Issue Type: Bug
> Components: API
> Affects Versions: 2.5
> Reporter: Joern Huxhorn
>
> Right now, any Message instance used to call any log method are simply sent
> as they are.
> Instead, the {{Throwable}} must be transformed into a {{ThrowableProxy}}.
> Custom {{Message}} implementations must be transformed into one of log4j's
> standard message implementations and care must be taken to convert the
> {{Parameters}} {{Object[]}} into {{String[]}} before the message is
> serialized.
> Otherwise, deserialization will fail if a custom {{Throwable}}, custom
> {{Message}} or custom parameter is not contained in the classpath of the
> application receiving the serialized {{LogEvent}}.
> I found those issues while implementing the circumvention for [Apache Commons
> statement to widespread Java object de-serialisation
> vulnerability|https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread]
> in [Lilith|http://lilithapp.com].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
