Skip to content

Instantly share code, notes, and snippets.

@gunnarmorling
Last active May 15, 2023 15:46
Show Gist options
  • Star 26 You must be signed in to star a gist
  • Fork 3 You must be signed in to fork a gist
  • Save gunnarmorling/8026d004776313ebfc65674202134e6d to your computer and use it in GitHub Desktop.
Save gunnarmorling/8026d004776313ebfc65674202134e6d to your computer and use it in GitHub Desktop.
<!-- 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

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

@vegegoku
Copy link

@max19931
Copy link

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

@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

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

@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

Updated to 2.17.0.

@els-hansenj
Copy link

@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

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

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