[
https://issues.apache.org/jira/browse/LOG4J2-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052749#comment-16052749
]
Mikael Ståldal commented on LOG4J2-1926:
----------------------------------------
OK, I see now why we wrap the values.
But I think that the current way you wrap it will open the serialization
security vulnerability CVE-2017-5645 we fixed with FilteredObjectInputStream in
LOG4J2-1863 since the nested ObjectInputStream does not respect the filtering.
And we cannot simply use a nested FilteredObjectInputStream since that class is
not in log4j-api, and even if it were it might be tricky to know which classes
to filter. (I don't think it would be wise to move FilteredObjectInputStream to
log4j-api).
And BTW, doesn't e.g. ObjectMessage (which does not do this wrapping) break
Lilith? Is LOG4J2-1226 really fixed?
> Remove dependency on RMI and Management APIs from log4j-api
> -----------------------------------------------------------
>
> Key: LOG4J2-1926
> URL: https://issues.apache.org/jira/browse/LOG4J2-1926
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.8
> Environment: Android
> Reporter: Oleg Kalnichevski
> Assignee: Remko Popma
>
> (Remko: Paraphrasing discussion on the log4j dev mailing list. Please feel
> free to update/modify):
> When the Apache HttpClient 5.0 library gets pulled into an Android project,
> the Lint static code analyzer reports two severe violations due to transitive
> dependency through Log4j APIs 2.8 on Java RMI and Java Management APIs.
> At the moment adding a transitive dependency on log4j2-api causes any Android
> build to fail with a scary invalid package error. Surely this error can be
> ignored with a custom lint rule but it may present a certain reason for
> concert to less experienced developers.
> This is caused by Log4j's use of MarshalledObject: User domain objects and
> exceptions are wrapped in MarshalledObject when LogEvents are serialized.
> This allows applications like Lilith to deserialize LogEvents even when not
> all domain classes are on the classpath (LOG4J2-1226).
> Consider finding a different way to solve this problem that does not require
> MarshalledObject.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
