logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1226) Message instances are simply serialized. They mustn't.
Date Fri, 15 Jul 2016 19:19:20 GMT

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

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

I would love to change the default layout to something else, but I don't think we can at this
point.  Instead, we should decide what our preferred layout is and update the documentation
to make it clear what our recommendation is.  I'd like to deprecate the behavior and say the
default will switch in a future release, but I'm not really sure how to do that.

I've said before that I would like to implement a new SocketAppender that uses Netty. When
that happens I would make sure SerializedLayout is not the default.

All that said, what Joern is asking for does need to be done. I was under the impression we
are already serializing objects that are passed to Async Loggers and in the Async Appender.

> 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