Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Gradle/Java: How to upgrade log4j safely?

Given the recent Log4J vulnerability what is the safest way to upgrade transitive dependencies in a gradle project? My project doesn't explicitly use log4j(it uses logback) but it has a number of dependencies that brings in the vulnerable versions(< 2.15.0). First, is it necessary to upgrade anything if my SLF4J uses logback? And if I were to upgrade, how do I force 2.15 to be present in classpath instead of the older version?

like image 650
Pepria Avatar asked Dec 11 '21 17:12

Pepria


People also ask

Is gradle affected by Log4j?

Note that the Gradle Build Tool itself is not impacted by this vulnerability as it does not use Log4j. Gradle uses SLF4J and a custom logging implementation not susceptible to the vulnerable string substitution. The Gradle Scala plugin uses the Zinc Scala compiler that has a dependency on a vulnerable version of Log4j.

What version of Log4j should I upgrade to?

2.17. 2 (for Java 8) is a recommended upgrade. Log4j 2.19. 0 is now available for production.

Where is Log4j dependency in gradle?

How to check the presence of Log4j vulnerable versions in gradle so that it would list all the dependencies including the transitive dependencies? ./gradlew -q dependencies|grep -i log4j - This should give you the version of log4j-dependencies (if any) that are used.


1 Answers

Add the following to your gradle.build file:

configurations.all {
  resolutionStrategy.eachDependency { details ->
    if (details.requested.group == 'org.apache.logging.log4j') {
      details.useVersion '2.17.1'
      details.because 'zero-day exploits suck'
    }
  }
}

dependencies {
…
}

Note that as the documentation points out:

the following mechanisms allow you to write rules which are directly injected into the resolution engine. Because of this, they can be seen as brute force solutions, that may hide future problems (e.g. if new dependencies are added). Therefore, the general advice is to only use the following mechanisms if other means are not sufficient.

I realize the OP asks for the "safest" way to upgrade dependencies -- I choose to interpret that as most-likely to remove zero-day exploits. Nevertheless, I do recognize that this brute force approach doesn't guarantee compatibility between libraries, but this should make sure no vulnerable versions of log4j end up in your dependency tree / builds.

You should of course run gradle dependencies after you make the change to be sure the changes took and you don't have any lingering versions with issues.

Update: removed the version comparison, as recommended here.

Update: increased version to 2.17.1

like image 106
Lunchbox Avatar answered Oct 17 '22 02:10

Lunchbox