Hi All, As I learned by reading this email chain that apache kafka can be vulnerable if JMS appender with JNDI lookup is enabled in the log4j configuration file which is "log4j.properties". We are using the "log4j.properties" file as it is coming with the kafka package. Are we vulnerable ? do we have to make any changes in the file to protect against the vulnerability ? What specific configuration line in the properties file relate to the vulnerability ? We have no configuration for "TopicBindingName" or "TopicConnectionFactoryBindingName" in the log4j.properties file. Does it mean we are safe ?
Thanks, Dhirendra. -----Original Message----- From: Brian Rickabaugh <apache....@rickabaugh.net> Sent: Wednesday, December 15, 2021 8:04 AM To: users@kafka.apache.org Subject: Re: CVE-2021-44228 – Log4j 2 Vulnerability I'll second that. Thank you! Brian Quoting Luke Chen <show...@gmail.com>: Hi Jun, It looks great and clear! Thank you for working on the public statement! Thank you. Luke On Wed, Dec 15, 2021 at 8:34 AM Jun Rao <j...@confluent.io.invalid> wrote: Hi, Everyone, Just to provide an update. https://kafka.apache.org/cve-list is now updated with this CVE. Thanks, Jun On Tue, Dec 14, 2021 at 3:30 PM Jun Rao <j...@confluent.io> wrote: Hi, Israel, Randall added some clarification for the connectors in the PR. Thanks, Jun On Tue, Dec 14, 2021 at 12:10 PM Israel Ekpo <israele...@gmail.com> wrote: Do we want to add a disclaimer that users need to check their connectors to see if it uses log4j2? Though the core library does not use this dependency, it is possible external connectors that use it could introduce vulnerabilities if they depend on the affected log4j2 version On Tue, Dec 14, 2021 at 1:40 PM Israel Ekpo <israele...@gmail.com> wrote: Sure I will take a look at it shortly On Tue, Dec 14, 2021 at 12:44 PM Jun Rao <j...@confluent.io.invalid> wrote: Hi, Luke, Thanks for the analysis. We are trying to put a public statement on this through this PR: https://github.com/apache/kafka-site/pull/388. If anyone has more feedback, we can iterate on the PR. Thanks, Jun On Tue, Dec 14, 2021 at 7:53 AM Murilo Tavares <murilo...@gmail.com> wrote: What about Kafka-Connect? Anyone has checked if any of the Confluent KafkaConnect docker images embed log4j v2? Thanks On Mon, 13 Dec 2021 at 21:39, Luke Chen <show...@gmail.com> wrote: Hi all, Here's the comments for CVE-2021-44228 vulnerability from SLF4J project. REF: http://slf4j.org/log4shell.html I think it's a analysis that worth reading. Most importantly, it has comments about log4j 1.x versions, which is currently Kafka used. I quote some sentences here for your reference: 1. As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228. 2. However, log4j 1.x comes with JMSAppender which will perform a JNDI lookup if enabled in log4j's configuration file, i.e. log4j.properties or log4j.xml. 3. In the absence of a new log4j 1.x release, you can remove JMSAppender from the log4j-1.2.17.jar artifact yourself. (commands are listed in the page <http://slf4j.org/log4shell.html>) 4. Therefore, in addition to hardening KNOWN vulnerable components in aforementioned frameworks, we also recommend that configuration files be protected against write access. In Unix-speak they should be read-only for all users, including the owner. If possible, they should also be monitored against changes and unauthorized manipulation. Thank you. Luke On Tue, Dec 14, 2021 at 12:55 AM David Ballano Fernandez < dfernan...@demonware.net> wrote: Thanks guys! On Mon, Dec 13, 2021 at 7:43 AM Brian Rickabaugh <br...@rickabaugh.net> wrote: I strongly recommend that the Kafka community publish a statement on this vulnerability. This Log4J exploit is getting a lot of publicity in my organization and a page to point our security team to would be very helpful. Brian Quoting Luke Chen <show...@gmail.com>: Due to this vulnerability is quite critical and "popular" in these days, should Kafka have an official announcement in our security cve list page or somewhere? (i.e.https://urldefense.proofpoint.com/v2/url?u=https-3A__kafka.apache.org_cve-2Dlist&d=DwIFaQ&c=qE8EibqjfXM-zBfebVhd4gtjNZbrDcrKYXvb1gt38s4&r=p-f3AJg4e4Uk20g_16kSyBtabT4JOB-1GIb23_CxD58&m=bgQoydMIn6_TMXjRt2Jw8AUS-IPeFX07xSqA4ONmNUDFJXnB5xNHw7TFiy6UD4gP&s=lGTK9XqyO0i5KkSD6aOpmRxCVx90zrXNRtOq0vtSPSc&e=) So far, my assessment is that, Kafka is not using log4j 2.x versions, so the risk is lower. Kafka is using log4j 1.x version. As long as users don't set the jms appender, with the *TopicBindingName* or *TopicConnectionFactoryBindingName *configured with the JNDI can handle (ex: "ldap://host:port/a";), it is safe. (usually we don't set the topic name or factory name to this kind offor name) One thing to add is that, we are currently working on upgrading log4j 1 to log4j 2 (KAFKA-9366 <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_KAFKA-2D9366&d=DwIFaQ&c=qE8EibqjfXM-zBfebVhd4gtjNZbrDcrKYXvb1gt38s4&r=p-f3AJg4e4Uk20g_16kSyBtabT4JOB-1GIb23_CxD58&m=bgQoydMIn6_TMXjRt2Jw8AUS-IPeFX07xSqA4ONmNUDFJXnB5xNHw7TFiy6UD4gP&s=wNhgW9w7vSqIYgBLQ1iOcfBsQg3vHcPHxChyXqQ2-K0&e=), and we'll make sure it upgrades to 2.15.0 or newer versions. Thank you. Luke On Sun, Dec 12, 2021 at 12:00 PM Luke Chen <show...@gmail.com> wrote: Hi David Ballano Fernandez and all, Some update here: Based on @TopStreamsNet's comment here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_logging-2Dlog4j2_pull_608-23issuecomment-2D991723301&d=DwIFaQ&c=qE8EibqjfXM-zBfebVhd4gtjNZbrDcrKYXvb1gt38s4&r=p-f3AJg4e4Uk20g_16kSyBtabT4JOB-1GIb23_CxD58&m=bgQoydMIn6_TMXjRt2Jw8AUS-IPeFX07xSqA4ONmNUDFJXnB5xNHw7TFiy6UD4gP&s=z2x4txhlSwAoPNTeuYxZH8IVCHoGkhLsfbhWDH-SVG4&e= log4j 1.x versions can still be vulnerable to this issue, but only when the jms configuration: *TopicBindingName* or *TopicConnectionFactoryBindingName* is set to something that JNDI can handle - for example "ldap://host:port/a";. In this way, JNDI will do exactly the same thing it does for 2.x. That is, 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input. So, in short, as long as you're using Kafka, and not setting the jms configuration: *TopicBindingName* or *TopicConnectionFactoryBindingName to something that JNDI can handle, it is safe! Thank you. Luke On Sat, Dec 11, 2021 at 4:23 PM Luke Chen <show...@gmail.com> wrote: Hi David Ballano Fernandez, Thanks for reporting this issue. Yes, this is the most critical 0-day vulnerability for security members. I've been investigating this CVE for a while, and I confirmed that log4j 1.x versions are not affected by this vulnerability. That is, Kafka, which is using log4j 1.x, is not affected by this vulnerability. So, users can safely use Kafka without worries! :) REF: Here, the PMC of log4j 2 comment on the PR to fix the vulnerability here https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_logging-2Dlog4j2_pull_608-23issuecomment-2D990494126&d=DwIFaQ&c=qE8EibqjfXM-zBfebVhd4gtjNZbrDcrKYXvb1gt38s4&r=p-f3AJg4e4Uk20g_16kSyBtabT4JOB-1GIb23_CxD58&m=bgQoydMIn6_TMXjRt2Jw8AUS-IPeFX07xSqA4ONmNUDFJXnB5xNHw7TFiy6UD4gP&s=6RYStOYjw2vQZteGALeXGun6DVhCKcs539cR9tr3m8A&e= and said: Update (2021-12-11 09:09 JST): according to this analysis https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ceki_status_1469449618316533762&d=DwIFaQ&c=qE8EibqjfXM-zBfebVhd4gtjNZbrDcrKYXvb1gt38s4&r=p-f3AJg4e4Uk20g_16kSyBtabT4JOB-1GIb23_CxD58&m=bgQoydMIn6_TMXjRt2Jw8AUS-IPeFX07xSqA4ONmNUDFJXnB5xNHw7TFiy6UD4gP&s=ZhLYIdqAKXaVPEbVpd3uce5dtisDqwoWaji_UMVM5Es&e= by @ceki https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ceki&d=DwIFaQ&c=qE8EibqjfXM-zBfebVhd4gtjNZbrDcrKYXvb1gt38s4&r=p-f3AJg4e4Uk20g_16kSyBtabT4JOB-1GIb23_CxD58&m=bgQoydMIn6_TMXjRt2Jw8AUS-IPeFX07xSqA4ONmNUDFJXnB5xNHw7TFiy6UD4gP&s=103KstS4K4BNNdpX7RDbGisXiPzc62Eq5yiO6DJgn8k&e= (the author of log4j 1.x), Log4j 1.x is not impacted, since it does not have lookups, and the JMS Appender only loads Strings from the remote server, not serialized objects. That is, log4j 1 is actually another project from log4j 2, and the author of the log4j 1 confirmed log4j 1 is not impacted by this vulnerability! Thank you Luke On Sat, Dec 11, 2021 at 6:42 AM David Ballano Fernandez < dfernan...@demonware.net> wrote: Hi All, I wonder if you guys have heard about this vulnerability https://urldefense.proofpoint.com/v2/url?u=https-3A__www.randori.com_blog_cve-2D2021-2D44228_&d=DwIFaQ&c=qE8EibqjfXM-zBfebVhd4gtjNZbrDcrKYXvb1gt38s4&r=p-f3AJg4e4Uk20g_16kSyBtabT4JOB-1GIb23_CxD58&m=bgQoydMIn6_TMXjRt2Jw8AUS-IPeFX07xSqA4ONmNUDFJXnB5xNHw7TFiy6UD4gP&s=TaOz7ebOBrjIW_i2K4MduRFI7vsBBUZMKr9B1K6JupI&e= affecting log4j v1 and v2 as far as i can see kafka 2.7 and 2.8 are using log4j v1. which is only affected if using jms appender. any thoughts? Thanks! Israel Ekpo Lead Instructor, IzzyAcademy.com https://izzyacademy.com/
