[
https://issues.apache.org/jira/browse/LOG4J2-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370656#comment-15370656
]
Ralph Goers edited comment on LOG4J2-1226 at 7/11/16 12:42 PM:
---------------------------------------------------------------
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.
That doesn't mean we won't do it, but I would expect that some other user is
going to raise an issue because they can't get their custom message to
serialize, which means the SerializedLayout would need an option to bypass the
behavior you are asking for - or more likely, an option is required to enable
the behavior you need.
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.
was (Author: [email protected]):
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]
