Hi Dhirendra, Please find the Kafka's public statement for this CVE in this CVE list page: https://kafka.apache.org/cve-list.
Thank you. Luke On Mon, Dec 20, 2021 at 2:21 PM Mailbox - Dhirendra Kumar Singh < dhirendr...@gmail.com> wrote: > 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 > <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/ > >
