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

Ralph Goers commented on LOG4J2-1226:
-------------------------------------

1. I understand the arguments you are making (and pretty much already did). My 
argument is that Java serialization is probably the worst serialization format 
you could choose and what you are asking here is that Log4j not allow Java to 
do "normal" Java serialization but customize the objects being passed to it.

2. In Log4j 2, the SocketAppender accepts a Layout. The SerializedLayout is the 
default but you can use any Layout, so if you support other serialization 
formats you should definitely use one of them. You won't get a 
ClassNotFoundException with them because you will just be getting data that you 
can do whatever you want with.

> 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