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://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!
