[jira] [Commented] (KAFKA-9366) Upgrade log4j to log4j2

["Fabrice Bauzac-Stehly (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485878#comment-17485878 ] 

Fabrice Bauzac-Stehly commented on KAFKA-9366:
----------------------------------------------

https://kafka.apache.org/cve-list claims to list all security
vulnerabilities that are fixed in released versions of Apache Kafka.
I understand this as "all other vulnerabilities are potentially
exploitable unless explicitly told otherwise".  Here is the list as of
2022-02-02 Wednesday:

- CVE-2017-12610 Authenticated Kafka clients may impersonate other
  users

- CVE-2018-1288 Authenticated Kafka clients may interfere with data
  replication

- CVE-2018-17196 Authenticated clients with Write permission may
  bypass transaction/idempotent ACL validation

- CVE-2019-12399 Apache Kafka Connect REST API may expose plaintext
  secrets in tasks endpoint

- CVE-2021-4104 Flaw in Apache Log4j logging library in versions 1.x

- CVE-2021-38153 Timing Attack Vulnerability for Apache Kafka Connect
  and Clients

- CVE-2021-44228 Flaw in Apache Log4j logging library in versions from
  2.0.0 and before 2.15.0

- CVE-2021-45046 Flaw in Apache Log4j logging library in versions from
  2.0-beta9 through 2.12.1 and from 2.13.0 through 2.15.0

- CVE-2022-23307 Deserialization of Untrusted Data Flaw in Apache
  Log4j logging library in versions 1.x

https://logging.apache.org/log4j/1.2/ lists several vulnerabilities
that affect log4j 1.x.  As of 2022-02-02 Wednesday:

- CVE-2019-17571 is a high severity issue targeting the
  SocketServer. Log4j includes a SocketServer that accepts serialized
  log events and deserializes them without verifying whether the
  objects are allowed or not. This can provide an attack vector that
  can be expoited.

  => NOT FIXED IN KAFKA?

- CVE-2020-9488 is a moderate severity issue with the
  SMTPAppender. Improper validation of certificate with host mismatch
  in Apache Log4j SMTP appender. This could allow an SMTPS connection
  to be intercepted by a man-in-the-middle attack which could leak any
  log messages sent through that appender.

  => NOT FIXED IN KAFKA?

- CVE-2021-4104 is a high severity deserialization vulnerability in
  JMSAppender. JMSAppender uses JNDI in an unprotected manner allowing
  any application using the JMSAppender to be vulnerable if it is
  configured to reference an untrusted site or if the site referenced
  can be accesseed by the attacker. For example, the attacker can
  cause remote code execution by manipulating the data in the LDAP
  store.

  => mitigated: one can remove JMSAppender from the log4j-1.2.17.jar
  artifact.

- CVE-2022-23302 is a high severity deserialization vulnerability in
  JMSSink. JMSSink uses JNDI in an unprotected manner allowing any
  application using the JMSSink to be vulnerable if it is configured
  to reference an untrusted site or if the site referenced can be
  accesseed by the attacker. For example, the attacker can cause
  remote code execution by manipulating the data in the LDAP store.

  => NOT FIXED IN KAFKA?

- CVE-2022-23305 is a high serverity SQL injection flaw in
  JDBCAppender that allows the data being logged to modify the
  behavior of the component. By design, the JDBCAppender in Log4j
  1.2.x accepts an SQL statement as a configuration parameter where
  the values to be inserted are converters from PatternLayout. The
  message converter, %m, is likely to always be included. This allows
  attackers to manipulate the SQL by entering crafted strings into
  input fields or headers of an application that are logged allowing
  unintended SQL queries to be executed.

  => NOT FIXED IN KAFKA?

- CVE-2022-23307 is a critical severity against the chainsaw component
  in Log4j 1.x. This is the same issue corrected in CVE-2020-9493
  fixed in Chainsaw 2.1.0 but Chainsaw was included as part of Log4j
  1.2.x.

  => mitigated: one can remove Chainsaw from the log4j-1.2.17.jar
  artifact.

From all that, it looks like there is a number of still-open
vulnerabilities in kafka induced by the use of log4j?  Can somebody
confirm?


> Upgrade log4j to log4j2
> -----------------------
>
>                 Key: KAFKA-9366
>                 URL: https://issues.apache.org/jira/browse/KAFKA-9366
>             Project: Kafka
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 2.2.0, 2.1.1, 2.3.0, 2.4.0
>            Reporter: leibo
>            Assignee: Dongjin Lee
>            Priority: Critical
>              Labels: needs-kip
>             Fix For: 3.2.0
>
>
> h2. CVE-2019-17571 Detail
> Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.
>  
> [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571]
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)