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