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 Mon, 11 Jul 2016 12:41:10 GMT

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


Mime
View raw message