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] [Comment Edited] (LOG4J2-1226) Message instances are simply serialized. They mustn't.
Date Mon, 11 Jul 2016 12:43:12 GMT

    [ 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: ralph.goers@dslextreme.com):
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