[jira] [Commented] (LOG4J2-1863) Add support for filtering input in TcpSocketServer and UdpSocketServer
[
https://issues.apache.org/jira/browse/LOG4J2-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630842#comment-17630842
]
Daniel Meyers commented on LOG4J2-1863:
---
I tried adding a customizable filter of this class during research paper pay to
[https://writemypapers4me.net/pay-for-research-paper/|https://writemypapers4me.net/pay-for-research-paper/].
This feature turned out to be really unnecessary in JmsServer, because it
depends on the basic configuration of the JMS server.
> Add support for filtering input in TcpSocketServer and UdpSocketServer
> --
>
> Key: LOG4J2-1863
> URL: https://issues.apache.org/jira/browse/LOG4J2-1863
> Project: Log4j 2
> Issue Type: New Feature
> Components: Receivers
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 2.8.2
>
>
> It is best practice to add a configurable class filter to ObjectInputStream
> usage when input comes from untrusted sources. Add this feature to
> TcpSocketServer and UdpSocketServer along with sensible default settings.
> This feature is unnecessary in JmsServer as that relies on the underlying
> configuration of the JMS server (e.g., ActiveMQ has a similar configuration
> option).
> h3. Security Details
> {code}
> CVE-2017-5645: Apache Log4j socket receiver deserialization vulnerability
> Severity: High
> CVSS Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
> Vendor: The Apache Software Foundation
> Versions Affected: all versions from 2.0-alpha1 to 2.8.1
> Description: When using the TCP socket server or UDP socket server to receive
> serialized log events from another application, a specially crafted binary
> payload can be sent that, when deserialized, can execute arbitrary code.
> Mitigation: Java 7+ users should migrate to version 2.8.2 or avoid using the
> socket server classes. Java 6 users should avoid using the TCP or UDP socket
> server classes, or they can manually backport the security fix from 2.8.2:
>
> Credit: This issue was discovered by Marcio Almeida de Macedo of Red Team at
> Telstra
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-1863) Add support for filtering input in TcpSocketServer and UdpSocketServer
[
https://issues.apache.org/jira/browse/LOG4J2-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16339319#comment-16339319
]
Donatien RIVIERE commented on LOG4J2-1863:
--
Log4j socket servers have been moved to "logging-log4j-tools" repository in a
"log4j-server" project since 2.9.0.
But this artifact "org.apache.logging.log4j:log4j-server" is not published to
any public maven repository, which makes it almost totally hidden, and unusable.
What is the plan about that ?
[https://git-wip-us.apache.org/repos/asf?p=logging-log4j-tools.git;a=tree;f=log4j-server;hb=HEAD]
> Add support for filtering input in TcpSocketServer and UdpSocketServer
> --
>
> Key: LOG4J2-1863
> URL: https://issues.apache.org/jira/browse/LOG4J2-1863
> Project: Log4j 2
> Issue Type: New Feature
> Components: Receivers
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 2.8.2
>
>
> It is best practice to add a configurable class filter to ObjectInputStream
> usage when input comes from untrusted sources. Add this feature to
> TcpSocketServer and UdpSocketServer along with sensible default settings.
> This feature is unnecessary in JmsServer as that relies on the underlying
> configuration of the JMS server (e.g., ActiveMQ has a similar configuration
> option).
> h3. Security Details
> {code}
> CVE-2017-5645: Apache Log4j socket receiver deserialization vulnerability
> Severity: High
> CVSS Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
> Vendor: The Apache Software Foundation
> Versions Affected: all versions from 2.0-alpha1 to 2.8.1
> Description: When using the TCP socket server or UDP socket server to receive
> serialized log events from another application, a specially crafted binary
> payload can be sent that, when deserialized, can execute arbitrary code.
> Mitigation: Java 7+ users should migrate to version 2.8.2 or avoid using the
> socket server classes. Java 6 users should avoid using the TCP or UDP socket
> server classes, or they can manually backport the security fix from 2.8.2:
>
> Credit: This issue was discovered by Marcio Almeida de Macedo of Red Team at
> Telstra
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
