[jira] [Comment Edited] (KAFKA-9366) Upgrade log4j to log4j2
[ https://issues.apache.org/jira/browse/KAFKA-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515252#comment-17515252 ] Akansh Shandilya edited comment on KAFKA-9366 at 3/31/22, 11:23 AM: [~showuon] I appreciate your dedication and efforts to resolve log4j 1.x EOL version from Kafka. Log4j 1.x is declared End-of-Life by Apache-log4j in 2015. Apache-Kafka is still using. As well as security scanners are reporting EOL version of log4j as vulnerability in Kafka, and there is little scope to explain it to whole world. [~showuon] please discuss and review to find a solution with user, who has blocked chance of log4j upgrade (log4j 1.x to log4j 2.x) in Kafka in 3.2.0 release. Or is there any plan to remove log4 1.x in 3.2.0 release? Please advise. was (Author: akansh): [~showuon] I appreciate your dedication and efforts to resolve log4j 1.x EOL version from Kafka. Log4j 1.x is declared End-of-Life by Apache-log4j in 2015. Apache-Kafka is still using. As well as security scanners are reporting EOL version of log4j as vulnerability in Kafka, and there is little scope to explain it to whole world. [~showuon] please discuss and review to find a solution with user, who has blocked chance of log4j upgrade (log4j 1.x to log4j 2.x) in Kafka in 3.2.0 release. > 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.3.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)
[jira] [Comment Edited] (KAFKA-9366) Upgrade log4j to log4j2
[ https://issues.apache.org/jira/browse/KAFKA-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515252#comment-17515252 ] Akansh Shandilya edited comment on KAFKA-9366 at 3/31/22, 11:21 AM: [~showuon] I appreciate your dedication and efforts to resolve log4j 1.x EOL version from Kafka. Log4j 1.x is declared End-of-Life by Apache-log4j in 2015. Apache-Kafka is still using. As well as security scanners are reporting EOL version of log4j as vulnerability in Kafka, and there is little scope to explain it to whole world. [~showuon] please discuss and review to find a solution with user, who has blocked chance of log4j upgrade (log4j 1.x to log4j 2.x) in Kafka in 3.2.0 release. was (Author: akansh): [~showuon] I appreciate your dedication and efforts to resolve log4j 1.x EOL version from Kafka. Log4j 1.x is declared End-of-Life by Apache-log4j in 2015. Apache-Kafka is still using. As well as security scanners are reporting EOL version of log4j as vulnerability in Kafka, and there is little scope to explain it to whole world. [~showuon] please discuss and review to find a solution with user, who has blocked chance of log4j upgrade (log4j 1.x to log4j 2.x) in Kafka in 3.2.0 release > 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.3.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)
[jira] [Comment Edited] (KAFKA-9366) Upgrade log4j to log4j2
[ https://issues.apache.org/jira/browse/KAFKA-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515252#comment-17515252 ] Akansh Shandilya edited comment on KAFKA-9366 at 3/31/22, 11:19 AM: [~showuon] I appreciate your dedication and efforts to resolve log4j 1.x EOL version from Kafka. Log4j 1.x is declared End-of-Life by Apache-log4j in 2015. Apache-Kafka is still using. As well as security scanners are reporting EOL version of log4j as vulnerability in Kafka, and there is little scope to explain it to whole world. [~showuon] please discuss and review to find a solution with user, who has blocked chance of log4j upgrade (log4j 1.x to log4j 2.x) in Kafka in 3.2.0 release was (Author: akansh): [~showuon] I appreciate your dedication and efforts to resolve log4j 1.x EOL version from Kafka. Log4j 1.x is declared End-of-Life by Apache-log4j in 2015. Apache-Kafka is still using. As well as security scanners are reporting EOL version of log4j as vulnerability in Kafka, and there is little scope to explain it to whole world. [~showuon] please discuss and review to find a solution with user, who has blocked chance of log4j upgrade (log4j 1.x to log4j 2.x) in Kafka. > 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.3.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)
[jira] [Commented] (KAFKA-9366) Upgrade log4j to log4j2
[ https://issues.apache.org/jira/browse/KAFKA-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515252#comment-17515252 ] Akansh Shandilya commented on KAFKA-9366: - [~showuon] I appreciate your dedication and efforts to resolve log4j 1.x EOL version from Kafka. Log4j 1.x is declared End-of-Life by Apache-log4j in 2015. Apache-Kafka is still using. As well as security scanners are reporting EOL version of log4j as vulnerability in Kafka, and there is little scope to explain it to whole world. [~showuon] please discuss and review to find a solution with user, who has blocked chance of log4j upgrade (log4j 1.x to log4j 2.x) in Kafka. > 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.3.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)
[jira] [Commented] (KAFKA-9366) Upgrade log4j to log4j2
[ https://issues.apache.org/jira/browse/KAFKA-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489791#comment-17489791 ] Akansh Shandilya commented on KAFKA-9366: - Voting has been done by multiple users, and more are the requests for upgrading log4j. Can we set or request ETA for log4j upgrade to log4j2. Any other challenge in doing so. [https://logging.apache.org/log4j/1.2/download.html] Log4j 1.x was End-Of-Llife on August 5, 2015. Kafka and Log4j, both are connected to Apache. As a strong community we need to think :: Does Apache-Kafka require more than 6 years of time to upgrade a log4j library, which was declared End-of-Life by Apache-log4j in 2015. > 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)
[jira] [Created] (KAFKA-13545) Workaround for mitigating CVE-2021-4104 Kafka
Akansh Shandilya created KAFKA-13545: Summary: Workaround for mitigating CVE-2021-4104 Kafka Key: KAFKA-13545 URL: https://issues.apache.org/jira/browse/KAFKA-13545 Project: Kafka Issue Type: Bug Affects Versions: 2.8.1 Reporter: Akansh Shandilya A new vulnerability is published today : https://nvd.nist.gov/vuln/detail/CVE-2021-4104 Kafka v2.8.1 uses log4j v1.x . Please review following information : Is Kafka v2.8.1 impacted by CVE-2021-4104? If yes, is there any workaround/recommendation available for Kafka v2.8.1 to mitigate CVE-2021-4104 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-13535) Workaround for mitigating CVE-2021-44228 Kafka
[ https://issues.apache.org/jira/browse/KAFKA-13535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458384#comment-17458384 ] Akansh Shandilya commented on KAFKA-13535: -- [~showuon] Thanks , will wait as per your suggestion. Regarding JMS Appender , found a log4j manual, but that is applicable for log4j 2.x.x. [https://logging.apache.org/log4j/2.x/manual/appenders.html] > Workaround for mitigating CVE-2021-44228 Kafka > --- > > Key: KAFKA-13535 > URL: https://issues.apache.org/jira/browse/KAFKA-13535 > Project: Kafka > Issue Type: Bug >Affects Versions: 2.8.1 >Reporter: Akansh Shandilya >Priority: Major > > Kafka v2.8.1 uses log4j v1.x . Please review following information : > > Is Kafka v2.8.1 impacted by CVE-2021-44228? > If yes, is there any workaround/recommendation available for Kafka v2.8.1 to > mitigate CVE-2021-44228 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-13535) Workaround for mitigating CVE-2021-44228 Kafka
[ https://issues.apache.org/jira/browse/KAFKA-13535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458016#comment-17458016 ] Akansh Shandilya commented on KAFKA-13535: -- Hi [~showuon], But as long as you're using Kafka, and not setting the log4j jms configuration: *TopicBindingName* or *TopicConnectionFactoryBindingName* to something that JNDI can handle, ex: "ldap://host:port/a"; >> Thanks a lot, for keep sharing of latest update. Do we have any recommended >> steps to validate something, i.e. log4j configuration filename etc. > Workaround for mitigating CVE-2021-44228 Kafka > --- > > Key: KAFKA-13535 > URL: https://issues.apache.org/jira/browse/KAFKA-13535 > Project: Kafka > Issue Type: Bug >Affects Versions: 2.8.1 >Reporter: Akansh Shandilya >Priority: Major > > Kafka v2.8.1 uses log4j v1.x . Please review following information : > > Is Kafka v2.8.1 impacted by CVE-2021-44228? > If yes, is there any workaround/recommendation available for Kafka v2.8.1 to > mitigate CVE-2021-44228 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (KAFKA-13535) Workaround for mitigating CVE-2021-44228 Kafka
Akansh Shandilya created KAFKA-13535: Summary: Workaround for mitigating CVE-2021-44228 Kafka Key: KAFKA-13535 URL: https://issues.apache.org/jira/browse/KAFKA-13535 Project: Kafka Issue Type: Bug Affects Versions: 2.8.1 Reporter: Akansh Shandilya Kafka v2.8.1 uses log4j v1.x . Please review following information : Is Kafka v2.8.1 impacted by CVE-2021-44228? If yes, is there any workaround/recommendation available for Kafka v2.8.1 to mitigate CVE-2021-44228 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-6737) Is Kafka imapcted by critical vulnerqbilty CVE-2018-7489
[ https://issues.apache.org/jira/browse/KAFKA-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421943#comment-16421943 ] Akansh Shandilya commented on KAFKA-6737: - Dear Ismael, Thanks a lot, for confirmation that Kafka does not use c3p0 in the classpath. Regarding Jackson upgrade to 2.9.5, what is expected release date and version. I am new to this site, so asking for help. With Best Regards, Akansh > Is Kafka imapcted by critical vulnerqbilty CVE-2018-7489 > > > Key: KAFKA-6737 > URL: https://issues.apache.org/jira/browse/KAFKA-6737 > Project: Kafka > Issue Type: Bug > Components: packaging, security, unit tests >Affects Versions: 0.10.1.0, 1.1.0, 1.0.1 >Reporter: Akansh Shandilya >Priority: Critical > > Kafka is using FasterXML jackson-databind before 2.8.11.1 and 2.9.x before > 2.9.5 , which allows unauthenticated remote code execution because of an > incomplete fix for the CVE-2017-7525 deserialization flaw. This is > exploitable by sending maliciously crafted JSON input to the readValue method > of the ObjectMapper, bypassing a blacklist that is ineffective if the c3p0 > libraries are available in the classpath. > > I have checked that all released versions of Kafka are using jackson-databind > before 2.8.11.1 and 2.9.x before 2.9.5. > There are three open questions: > Question1: Is Kafka imapcted by critical vulnerqbilty CVE-2018-7489? > [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7489] > Question2: If answer of first question is Yes. Is there any workaround to fix > it on released version. > Question3: If answer of first question is Yes. Should we fix it in future > versions? > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-6737) Is Kafka imapcted by critical vulnerqbilty CVE-2018-7489
Akansh Shandilya created KAFKA-6737: --- Summary: Is Kafka imapcted by critical vulnerqbilty CVE-2018-7489 Key: KAFKA-6737 URL: https://issues.apache.org/jira/browse/KAFKA-6737 Project: Kafka Issue Type: Bug Components: packaging, security, unit tests Affects Versions: 1.0.1, 1.1.0, 0.10.1.0 Reporter: Akansh Shandilya Kafka is using FasterXML jackson-databind before 2.8.11.1 and 2.9.x before 2.9.5 , which allows unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 deserialization flaw. This is exploitable by sending maliciously crafted JSON input to the readValue method of the ObjectMapper, bypassing a blacklist that is ineffective if the c3p0 libraries are available in the classpath. I have checked that all released versions of Kafka are using jackson-databind before 2.8.11.1 and 2.9.x before 2.9.5. There are three open questions: Question1: Is Kafka imapcted by critical vulnerqbilty CVE-2018-7489? [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7489] Question2: If answer of first question is Yes. Is there any workaround to fix it on released version. Question3: If answer of first question is Yes. Should we fix it in future versions? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
