[
https://issues.apache.org/jira/browse/LOG4J2-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370227#comment-15370227
]
Ralph Goers commented on LOG4J2-1226:
-------------------------------------
Joern, is there any possibility of using some other serialization format such
as JSON? These kinds of problems are going to happen since Log4j supports
these kinds of interesting things. To be honest, I am not sure what you would
expect a CustomMessage to be serialized to, other than whatever serialization
it implements. If you were using a serialization protocol such as JSON you
wouldn't really need to convert the objects back into their original form as
you would basically just be getting keys and values.
> 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]
