Confirmation that clickhouse-jdbc is not affected by CVE-2021-44228?

[hodgesrm]

Hi, we're checking for vulnerabilities in ClickHouse due to CVE-2021-44228 (Log4Shell log4j vulnerability). It affects log4j 2 versions <= 2.14.1.

So far as I can tell from analysis of the code, the following are true and there's no vulnerability.

1. clickhouse-jdbc uses SLF4J 1.2, which is intended as an adapter on Log4j 1.2, which is not affected.
2. Running mvn package downloads log4j-1.2.17.jar, which does not contain affected code.

Here's a grep of references to log4j in relevant pom.xml and github config files.

 ./clickhouse-client/pom.xml:            <artifactId>slf4j-log4j12</artifactId>
./clickhouse-http-client/pom.xml:            <artifactId>slf4j-log4j12</artifactId>
./clickhouse-jdbc/src/test/resources/log4j.properties:log4j.rootLogger=WARN, STDOUT
./clickhouse-jdbc/src/test/resources/log4j.properties:#log4j.category.ru.yandex.clickhouse=DEBUG
./clickhouse-jdbc/src/test/resources/log4j.properties:#log4j.logger.org.apache.http=DEBUG
./clickhouse-jdbc/src/test/resources/log4j.properties:log4j.appender.STDOUT=org.apache.log4j.ConsoleAppender
./clickhouse-jdbc/src/test/resources/log4j.properties:log4j.appender.STDOUT.layout=org.apache.log4j.PatternLayout
./clickhouse-jdbc/src/test/resources/log4j.properties:log4j.appender.STDOUT.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.sss} [%t] [%-5p] {%c{1}:%L} - %m%n
./clickhouse-jdbc/pom.xml:            <artifactId>slf4j-log4j12</artifactId>
./.github/workflows/benchmark.yml:          find . -type f -name "log4j.*" -exec rm -fv '{}' \;
./.github/workflows/benchmark.yml:          find . -type f -name "log4j.*" -exec rm -fv '{}' \;
./.github/workflows/release.yml:          find . -type f -name "log4j.*" -exec rm -fv '{}' \;
./.github/workflows/third_party_libs.yml:          find . -type f -name "log4j.*" -exec rm -fv '{}' \;
./.github/workflows/analysis.yml:          find . -type f -name "log4j.*" -exec rm -fv '{}' \;
./pom.xml:                <artifactId>slf4j-log4j12</artifactId>

If there's a vulnerability it could only be because a user deployed their own version of Log4j in an application or altered the clickhouse-jdbc build.

Can someone confirm this reasoning?

[zhicwu]

Actually log4j 1.x has issue too. See CVE-2021-4104.

Anyway, log4j is only used for testing. So yes, if there's a vulnerability it could only be because a user deployed their own version of Log4j in an application or altered the clickhouse-jdbc build. Moreover, please pay attention that besides JNDI lookup, log4j also supports showing environment variables and system properties, which may expose sensitive information(e.g. user, password, and token etc.) in log unexpectedly.

I'll make sure log4j will be removed from both develop and master branches starting from 0.3.2.

[zhicwu]

Removed in d9e9df8.

java.logging will be used when slf4j is not available - see here for details.

[hodgesrm]

Hi @zhicwu, your reply is greatly appreciated. We have mentioned this on the Altinity Blog in a writeup on CVE-2021-44228 and will continue to watch responses here. You can also email security at altinity.com if there are additional concerns you would like us to communicate.

Robert Hodges, Altinity

[zhicwu]

Just released 0.3.2. If there's no critical issue, I'll release the artifacts to maven central tomorrow.