Published on

Dealing with the log4j issue

Authors

A serious vulnerability has been identified in the log4j framework. This has been thoroughly documented for example Microsoft has an extensive write up here.

Given the prevalence of log4j patching, it properly can be tricky. To this end, I ended up using a 2 prong approach:

  • Confirm a codebase has the issue
  • Configure Gradle to patch the issue

Confirm a codebase has the issue

I found various solutions online but they were a pain to run and I was not 100% sure the issue had been resolved. In the end, I opted for a general jar/container scanning solution in the form of the excellent Grype.

I then installed this locally and set up a makefile target in each of my repos to easily run the scan against a jar. This scan checks for all vulnerabilities and not just for log4j. The target looks as follows:

security-scan-jar: clean build## Scans the latest built jar for vulnerabilities
   grype build/libs/myJar-*.jar

The output looks as follows:

NAME                     INSTALLED     FIXED-IN      VULNERABILITY        SEVERITY
...
log4j-api                2.16.0        2.17.0        GHSA-p6xc-xr62-6r2g  High
log4j-api                2.16.0                      CVE-2021-45105       High
log4j-core               2.16.0        2.17.0        GHSA-p6xc-xr62-6r2g  High
log4j-core               2.16.0                      CVE-2021-45105       High
log4j-to-slf4j           2.16.0                      CVE-2021-45105       High
...

In this case, I have targets called clean and build that clean and build a fresh jar respectively.

I also created another target to scan the built docker image:

security-scan-docker-prod: docker-build-prod ## Scans the docker prod container for vulnerabilities
   grype $(DOCKER_REPO_URI)/$(DOCKER_IMAGE_NAME):$(CURRENT_GIT_HASH) --scope all-layers

In my case, I set up makefile variables for the above items that correspond to the name. The git hash is used as part of the build process to tag the image with the current git hash.

Configure Gradle to patch the issue

The online examples were not clear and did not seem to solve the issue when I ran the scan. In the end, what worked for me was the following:

...
configurations{
    runtime.exclude group: "log4j", module: "log4j"
}

configurations.all {
    resolutionStrategy.eachDependency { details ->
        if (details.requested.group == 'org.apache.logging.log4j') {
            details.useVersion '2.17.0'
            details.because 'CVE-2021-44228, CVE-2021-45046, CVE-2021-45105: Log4j vulnerable to remote code execution and other critical security vulnerabilities'
        }
    }
}

dependencies {
...

The configurations are needed as:

  • runtime.exclude group: "log4j", module: "log4j": this does not allow transitive dependencies for really old versions of log4j (the pre-apache ones). You will need to run your app to make sure this does not break anything
  • The second configuration ensures that all log4j dependencies use the patched version. Other examples online only patch core and may miss other log4j dependencies (core is likely where the main issue is but better to be safe)

Resources