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 11:28:11 GMT

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

Joern Huxhorn commented on LOG4J2-1226:

I certainly have other formats for receiving logging events but that isn't really the point.

Logback, Log4j1 and Log4j2 all support something like a {{SocketAppender}} that is sending
serialized events. That functionality is used by [Chainsaw|https://logging.apache.org/chainsaw/index.html],
[Lilith|http://lilithapp.com] and [Beagle|http://logback.qos.ch/beagle/], to name a few.

You provide that functionality with {{org.apache.logging.log4j.core.appender.SocketAppender}}
and I'd like to properly support this appender implementation in Lilith. That functionality
is currently broken.

Deserialization is only working if the serialized class is available in the deserializing

While you could argue that a certain {{Message}} implementation would be required on the receiving
end (which I don't agree with), this is simply impossible in case of {{Throwable}} hierarchies
since you'd essentially have to keep the entire classpath of the logging application in the
receiving ends classpath. You just can't know which {{Throwable}} classes by which third-party
dependency will end up in the cause/suppressed fields. So you need to use {{org.apache.logging.log4j.core.impl.ThrowableProxy}}
or something like it instead of serializing the original {{Throwable}}.

I'd expect receiving of events to work regardless of the actual {{Message}} class being used.
This can only be achieved by mapping non-standard (i.e. not included in the log4j2 distribution)
{{Message}} implementations to one of the standard ones before serializing, (e.g. something
like {{org.apache.logging.log4j.message.SimpleMessage}}, but supporting {{Throwable}}/{{ThrowableProxy}}
which is currently always {{null}} in {{SimpleMessage}}).

And serializing one of the standard log4j2 message types *must always* sanitize their content,
e.g. by converting arbitrary non-standard classes (i.e. classes not contained in log4j2 distribution)
used as parameter to {{String}} before serializing.

Not doing so would (beside potential {{ClassNotFoundException}}) also open up an attack vector
against applications receiving events that don't use a narrow class whitelist like I'm doing
in Lilith (see [Apache Commons statement to widespread Java object de-serialisation vulnerability|https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread]).

But I already wrote all that in my original description.

> 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
> 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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message