[
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 classloader.
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 {{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: [email protected]
For additional commands, e-mail: [email protected]
