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 <[email protected]> wrote: > Sure I will take a look at it shortly > > On Tue, Dec 14, 2021 at 12:44 PM Jun Rao <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 < >> > > [email protected]> wrote: >> > > >> > > > Thanks guys! >> > > > >> > > > On Mon, Dec 13, 2021 at 7:43 AM Brian Rickabaugh < >> [email protected] >> > > >> > > > 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 <[email protected]>: >> > > > > >> > > > > > 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 >> > > > > of >> > > > > > for 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 <[email protected]> >> > > 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 <[email protected]> >> > > 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 < >> > > > > >>> [email protected]> 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/ >
