Is neo4j 3.5 impacted by CVE-2021-44228?

Viewed 493

I found that only neo4j > 4.2 is impacted by this vulnerability (here and here )

But in neo4j 3.5.21 pom I see a dependency to log4j (here):

<dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.17</version>
</dependency>

So is this version really safe for use in production environment right now ?

2 Answers

Is seems that log4j version 1.2.17 is used in neo4j 3.5.21 and this version is not vulnerable to https://nvd.nist.gov/vuln/detail/CVE-2021-44228 as the vulnerability was introduced with version 2.10.0.

In any way log4j version 1.2.17 is vulnerable to https://nvd.nist.gov/vuln/detail/CVE-2019-17571 which has a score of 9.8 out of 10. It is a different attack vector maybe harder to exploit, but same as critical and should not be used in production.

You should update your neo4j version in any way.

The sky is not falling. To be clear Log4j 1.2.17 does NOT suffer from the ZDV. Are you running the rarely used network socket appender or JDBC appender servers? Is Neo4j? (I don't think so.) If you are not, then there is no reason to urgently toss software in the trash that relies on Log4j 1.x.*

One thing for sure is that Log4j2 is a breaking API change, which means you cannot just stuff a new JAR in and hope it works. (Package names and config specs changed.) If code is written well using a logging abstraction layer, like SLF4J, then it's a snap. However, if code relies on programmatic config settings, there will be pain. Upgrading to Log4j2 can be a non-trivial task.

* Note that Log4j 1.x has been out of its support window for a few years now. Also, Log4j2 was a complete rewrite of the API that is less resource intensive, less locking and quite faster (thanks to the LMAX Disruptor). There are reasons to upgrade but not as an emergency.

Related