[
https://issues.apache.org/jira/browse/LOG4J2-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370756#comment-15370756
]
Joern Huxhorn commented on LOG4J2-1226:
---------------------------------------
We don't need to discuss the pros and cons of Java serialization. I'm aware
that it sucks and wouldn't use it myself for various reasons. My custom Logback
appender is using gzipped protobuf, for example.
Both Logback and log4j1 have their own version of {{ThrowableProxy}} instead of
{{Throwable}} and neither is sending raw serialized objects as part of their
events. "Normal" Java serialization behavior would also mean that a
{{NotSerializableException}} is thrown if one of the components isn't
{{Serializable}} (see {{Serializable}} javadoc). I doubt that logging events
should work like that and would argue that a non-default behavior is required
anyway.
The thing is that you provide a {{SocketAppender}} which people are using in
combination with Lilith under the valid assumption that log4j2 behaves as
reliable as Logback and log4j1 with their respective {{SocketAppender}} - which
it doesn't.
You are not the project receiving the complaints. Lilith is.
The problem won't manifest in the application that is sending the events but in
the application that is receiving the events. Thus the users assume that the
"bug" is in the receiving application. Which it isn't. One example is [this
issue|https://github.com/huxi/lilith/issues/21] but I received multiple other
cries for help via mail.
This also means that just implementing a different layout won't fix the problem
at all. People would still use the {{SocketAppender}} with the default layout
and spam me with their support questions. Feel free to keep the current
{{SerializedLayout}} in the code base (I frankly don't see any reasonable use
case for it) but *please* implement a robust alternative that is *used by
default*.
> 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]
