[ 
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 {{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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to