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://kafka.apache.org/cve-list)
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://issues.apache.org/jira/browse/KAFKA-9366>), 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://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301 > 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://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126> >> and said: >> >> *Update (2021-12-11 09:09 JST): according to this analysis >> <https://twitter.com/ceki/status/1469449618316533762> by @ceki >> <https://github.com/ceki> (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://www.randori.com/blog/cve-2021-44228/ 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! >>> >>
