logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joern Huxhorn (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1226) Message instances are simply serialized. They mustn't.
Date Mon, 11 Jul 2016 13:35:11 GMT

    [ 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message