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

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

Would it be an idea to have a "safe" variant of the SerializedLayout (either 
with a parameter or a different name altogether) that would serialize any 
potentially problematic fields as Strings instead of as their native type?
Throwable can be serialized as ThrowableProxy (I actually thought we did this 
already...)

Not sure how to convert Message parameters to Strings before serialization. 
Perhaps let our built-in Messages have a serialization proxy to serialize to 
"safe" form.

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

Reply via email to