[jira] [Commented] (LOG4J2-1226) Message instances are simply serialized. They mustn't.

["Remko Popma (JIRA)" <ji...@apache.org>]

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

Remko Popma commented on LOG4J2-1226:
-------------------------------------

Perhaps the technique used for LOG4J2-1663 can be applied here also.

Log4jLogEvent.LogEventProxy can wrap the original Message object in a {{MarshalledObject}}, and in addition keep a String representation of this Message. 

If an error is encountered during _serialization_, only the String is captured and serialized.

During deserialization, we first attempt to return the result of deserializing the MarshalledObject. If this succeeds, that is the Message instance returned. If this fails, we return a SimpleMessage with the string message.

This should solve the ClassNotFoundException issues for Lillith, and at the same time allows users to serialize and deserialize custom Messages without loss of information, provided all the required classes are in the classpath during deserialization.

> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org