Log4j CVE-2021-44228 Vulnerability

[thehale]

Actual (problem) behavior

tnoodle-lib depends on a version of log4j that includes a severe security vulnerability as described here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Expected behavior

tnoodle-lib should depend on log4j version 2.16.0 or later. This should be as simple as updating a build dependency and running some tests to make sure nothing breaks.

Steps To Reproduce

1. Build tnoodle-lib or a dependent project like my tnoodle-cli and see that it downloads log4j version 2.13.3

Desktop (please complete the following information):

• OS: MacOS and Windows
• Browser including version n/a
• TNoodle Version: latest (0.18.0)
  • Java version: I'm using Java 11 which is generally considered safe from this CVE, but since tnoodle-lib also runs on Java 8, it should be upgraded to prevent any issues from users of that Java version.

Screenshots [OPTIONAL])

My gradle build cache after building tnoodle-lib from source showing the dependency on a vulnerable version of log4j

Additional context [OPTIONAL]

I'll just share the link to the official CVE description again for ease of access. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

[thehale]

Running gradle dependencies also gives some additional insight on the source of this dependency.

It looks like the dependency on log4j might be coming as a transient dependency from scrambler-threephase or scrambler-min2phase in which case those projects (which I believe are made by many of the same developers that built this project) will need to update their build scripts.

[thehale]

Just for full context, I think its worth mentioning that while this CVE is rated as extremely severe, there aren't many places where untrusted user input could be inadvertently passed through to the logging framework to exploit the vulnerability, especially since most users of this library don't have it available as a publicly accessible webserver. As such, the impact of this issue is probably pretty low. That said, it's probably best practice not to leave maximally rated security issues lying around in the project :P

[gregorbg]

Hello Joseph, thank you for reporting this issue! As far as I'm concerned, the CVE only affects Apache log4j while we are using logback-classic. Even in your screenshot I cannot see any direct reference to log4j. Could you please explain how this CVE affects TNoodle?

[gregorbg]

I have just merged https://github.com/thewca/tnoodle-lib/pull/37. Can you please pull from master and check whether you still get any bad/undesirable CVE dependencies?

[thehale]

Even in your screenshot I cannot see any direct reference to log4j. Could you please explain how this CVE affects TNoodle?

The second screenshot confused me too since I didn't see log4j in the direct list of dependencies. I just noticed that a vulnerable version of log4j appeared in my Gradle build cache after building tnoodle-lib on a new computer that hadn't used Gradle before (the first screenshot in the original issue). I'm not familiar enough with Java's logging ecosystem to pinpoint where that might have come from yet.

Can you please pull from master and check whether you still get any bad/undesirable CVE dependencies?

I cleared out my Gradle build cache, pulled the latest version from master and rebuilt. Log4J still appears in the Gradle build cache but it's now a non-vulnerable version.

Looks like this issue is resolved once this latest version is pushed to the central Maven repository. Thanks!

[gregorbg]

Closing as 0.18.1 is on Maven Central.