logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1226) Message instances are simply serialized. They mustn't.
Date Mon, 07 Nov 2016 23:14:58 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645784#comment-15645784

Remko Popma commented on LOG4J2-1226:

Thanks for confirming that the fix solves the serialization issue in the description.

About the semantics of the Message::getThrowable method, this needs to be better documented.
This method is only called by Log4j when the application logs with one of the log(String,
Object...) methods (including the unrolled vararg variants). 

In this case the last argument may be a Throwable. The ParameterizedMessage will consume all
parameters and give back the last argument if it was a Throwable. Once that is done Message::getThrowable
is never called. Layouts and Appenders do not generally look at the Message::getThrowable
since they receive the Throwable separately (in LogEvent::getThrown).

If you want to log a Throwable with a pre-existing Message object, you need to use one of
the log(Message,Throwable) methods.

> 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
>            Assignee: Remko Popma
>             Fix For: 2.8
> 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