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