Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
<!-- plug-in configuration to put into your parent POM for avoiding any usages of
outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
latest version of log4j2 at
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>ban-bad-log4j-versions</id>
<phase>validate</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<bannedDependencies>
<excludes>
<exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
</excludes>
</bannedDependencies>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
...
@fmarot
Copy link

fmarot commented Dec 11, 2021

Thanks for the snippet. I would add a comment mentionning "Log4Shell" as it's the official name of the vulnerability and would allow readers of this code to find the reasonning about banning this dependency in a few month or so, when everybody will have forgotten about it.

@gunnarmorling
Copy link
Author

gunnarmorling commented Dec 11, 2021

Good point, @fmarot 👍. Added a clarifying comment to the top.

@vegegoku
Copy link

vegegoku commented Dec 12, 2021

@max19931
Copy link

max19931 commented Dec 13, 2021

try against all repos listed here: https://github.com/apache/log4j/network/dependents

@worace
Copy link

worace commented Dec 13, 2021

Any chance anyone has come across a version of this for sbt (scala build tool)?

@hashhar
Copy link

hashhar commented Dec 14, 2021

Reminder that if you are adding this to a pom that already inherits from a parent POM you likely want something like:

          <bannedDependencies>
            <excludes combine.children="append">
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>

This will ensure that the definition in your POM doesn't overwrite the one inherited from parent and instead appends to it.

@mebe1012
Copy link

mebe1012 commented Dec 15, 2021

Thx for the snippet.
You might want to update your snippet to exclude 2.15.0 as well, as according to https://www.lunasec.io/docs/blog/log4j-zero-day/ (update from yesterday) the 2.15.0 version has still a limited vulnerability

@gunnarmorling
Copy link
Author

gunnarmorling commented Dec 15, 2021

Good point indeed, @mebe1012. Updated the gist accordingly, and took the liberty to update @hashhar's comment as well.

@mojadita
Copy link

mojadita commented Dec 16, 2021

Sorry, pardon for my ignorance. Should the patch be added to the build -> plugins path or to the build -> pluginManagement -> plugins path? I have included in both points (alternatively) and I still see in the dependencies a log4j-1.2.15.jar file: Is that ok? It's an indirect dependency I don't see how to take away. We normally use logback-classic-1.2.1.jar should we update the dependency?

@gunnarmorling
Copy link
Author

gunnarmorling commented Dec 16, 2021

@mojadita, put it to build/plugins. That you see log4j-1.2.15.jar despite having this rule in place is expected, as this is a different group id and artifact id (and log4j 1.x is not affected by the RCE CVE). You still may want to consider to upgrade either to the latest log4j 2.x or to move to an alternative such as Logback, as log4j 1.x hasn't been actively maintained for several years now and has other (albeit less critical) known CVEs.

@Pavanreddym
Copy link

Pavanreddym commented Dec 17, 2021

With the plugin added along with to project pom file, build fails if it finds any banned versions (even with transitive dependency of vulnerable log42 version) and wondering if there is way to avoid the build failure but rely on valid log4 versions provided by the project pom file. Not sure if this even is a good case :)

@thedevappsecguy
Copy link

thedevappsecguy commented Dec 20, 2021

@gunnarmorling
Thank you for the snippet.
You might want to update your snippet to exclude 2.16.0 as well ? Apache has released 2.17.0 , as new CVE is disclosed overnight by Apache CVE-2021-45105,Fixed in Log4j 2.17.0

@gunnarmorling
Copy link
Author

gunnarmorling commented Dec 20, 2021

Updated to 2.17.0.

@els-hansenj
Copy link

els-hansenj commented Dec 20, 2021

@gunnarmorling I can only get this to work if I use brackets instead of parenthesis, i.e.

<exclude>org.apache.logging.log4j:log4j-core:[,2.16.0]</exclude>

instead of

<exclude>org.apache.logging.log4j:log4j-core:(,2.16.0)</exclude>

The documentation at https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html also seems to indicate that without being completely explicit

@thedevappsecguy
Copy link

thedevappsecguy commented Dec 29, 2021

You might want to update your snippet to exclude 2.17.0 as well ? Apache has released 2.17.1 , as new CVE is disclosed by Apache CVE-2021-44832,Fixed in Log4j 2.17.1
https://logging.apache.org/log4j/2.x/security.html

@sbhutkar
Copy link

sbhutkar commented Jan 18, 2022

Adding to what @vegegoku reference posted:

Here is a link which might be helpful for Gradle projects
https://blog.gradle.org/log4j-vulnerability

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment