Debezium 1.8 vulnerabilities

162 views
Skip to first unread message

Pavan Manda

unread,
Feb 4, 2022, 6:01:16 AM2/4/22
to debezium
Hi Team,
We are receiving log4j vulnerability error form Kafka connect. CVE-2022-23307 is a new vulnerability  introduced few days back. We are seeing this issue inspite of using Debezium 1.8 version. Could you please let us know if any workaround? Below is our wrapper project pom file. Please suggest if any changes needed? (Or) Can we make. any changes to the Dockerfile in the wrapper project to resolve this issue. Pasted our Docker file below.

pom.xml in our wrapper project (Custom one derived from base image):
<properties>
<java.version>11</java.version>
<log4j2.version>2.17.1</log4j2.version>
<log4j.version>2.17.1</log4j.version>
</properties>

<dependencies>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
<version>1.18.22</version>
</dependency>

<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.17.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.17.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-to-slf4j</artifactId>
<version>2.17.1</version>
</dependency>

<!-- https://mvnrepository.com/artifact/org.slf4j/slf4j-api -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.35</version>
</dependency>

<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>connect-api</artifactId>
<version>3.1.0</version>
<exclusions>
<exclusion>
<artifactId>slf4j-api</artifactId>
<groupId>org.slf4j</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>
</dependencies>

Dockerfile in our wrapper project (Custom one derived from base image):
FROM <repo>/debezium/connect:1.8.0.Final
ENV DEBEZIUM_DIR=$KAFKA_CONNECT_PLUGINS_DIR/debezium-transformer

RUN mkdir $DEBEZIUM_DIR
COPY target/*.jar $DEBEZIUM_DIR

COPY src/main/resources/certs/* /home/
COPY src/main/resources/kafka_connect.conf /home/
COPY java.config /etc/crypto-policies/back-ends/
#Uncomment below line for Local testing
#COPY src/main/resources/connect-auth.properties /home/

ENV CONNECT_SSL_ENDPOINT_IDENTIFICATION_ALGORITHM=
ENV CONNECT_PRODUCER_SSL_ENDPOINT_IDENTIFICATION_ALGORITHM=
ENV CONNECT_REST_EXTENSION_CLASSES=org.apache.kafka.connect.rest.basic.auth.extension.BasicAuthSecurityRestExtension

ENV JAVA_TOOL_OPTIONS -Djava.security.auth.login.config=/home/kafka_connect.conf
EXPOSE 8080 8778 9779 8083

Regards
~PM

Gunnar Morling

unread,
Feb 4, 2022, 6:34:09 AM2/4/22
to debezium
To be very clear, there is no log4j-related vulnerability in Debezium itself, simply due to the fact that Debezium doesn't depend on log4j (it used to do so for *tests only*, and we just recently replaced that with Logback). As for the container images, I have already replied to your earlier mail, please don't start multiple threads on the same topic.

Now, if your question is about pulling in vulnerable log4j versions as a transitive dependency of your Java application (e.g. via Kafka's "connect-runtime" artifact), you may consider replacing that dependency with a stripped one (similar to what Debezium does for the log4j JAR in its container images), which for instance you maintain in your own local Maven repository server. There's also a log4j fork created by the original log4j author which supposedly addresses (some of) the CVEs in 1.x, but I have not tried this one out, so I can't comment on its usefulness. In any case it's also worth investigating whether any of these CVEs actually affects your specific usage, some if not all of them are about classes which you explicitly have to opt into using via your configuration.

Best,

--Gunnar


Reply all
Reply to author
Forward
Message has been deleted
0 new messages