logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joern Huxhorn (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1226) Message instances are simply serialized. They mustn't.
Date Thu, 14 Jul 2016 14:24:20 GMT

    [ 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
> 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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message