Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mitigations for log4j vulnerability in Gradle builds #19300

Closed
big-guy opened this issue Dec 13, 2021 · 4 comments
Closed

Mitigations for log4j vulnerability in Gradle builds #19300

big-guy opened this issue Dec 13, 2021 · 4 comments

Comments

@big-guy
Copy link
Member

big-guy commented Dec 13, 2021

A RCE vulnerability in log4j has been found that affects certain combinations of Java and applications using log4j 2.

This is a critical vulnerability that is actively being exploited.

While Gradle itself is not directly impacted by this, we should provide some mitigations and recommendations for Gradle users.

The following has been done in Gradle:

  • Ensure Zinc compiler does not put a vulnerable Log4j on a classpath. This is done by upgrading log4j-core to 2.16.0 on the zinc compiler classpath when using the scala plugin.
  • Protect buildscript classpath from having vulnerable Log4j. This is done by adding a constraint that rejects known vulnerable versions [2.0, 2.16)and requires2.16.0`

More information on our blog post.

@ZakTaccardi
Copy link

ZakTaccardi commented Dec 13, 2021

side note - but an interesting feature would be the ability to ensure that certain libraries/versions with vulnerabilities are not a part of the build - and if they are somehow introduced - fail the build.

ljacomet added a commit that referenced this issue Dec 13, 2021
No need for a logger implementation for compilation.

Issue #19300
ljacomet added a commit that referenced this issue Dec 13, 2021
This makes sure a log4j vulnerable version is not available for Zinc
compilation even though it is actually not used by default.

Issue #19300
ljacomet added a commit that referenced this issue Dec 14, 2021
This now uses a combination of require and reject instead of a strictly,
which will allow updates beyond the 2.x line. The previous solution was
effectively preventing that with no way for the user to change that.

Issue #19300
ljacomet added a commit that referenced this issue Dec 14, 2021
This now uses a combination of require and reject instead of a strictly,
which will allow updates beyond the 2.x line. The previous solution was
effectively preventing that with no way for the user to change that.

Issue #19300
ljacomet added a commit that referenced this issue Dec 14, 2021
This now uses a combination of require and reject instead of a strictly,
which will allow updates beyond the 2.x line. The previous solution was
effectively preventing that with no way for the user to change that.

Issue #19300
ljacomet added a commit that referenced this issue Dec 14, 2021
This now uses a combination of require and reject instead of a strictly,
which will allow updates beyond the 2.x line. The previous solution was
effectively preventing that with no way for the user to change that.

Issue #19300
ljacomet added a commit that referenced this issue Dec 14, 2021
This now uses a combination of require and reject instead of a strictly,
which will allow updates beyond the 2.x line. The previous solution was
effectively preventing that with no way for the user to change that.

Issue #19300
ljacomet added a commit that referenced this issue Dec 14, 2021
This now uses a combination of require and reject instead of a strictly,
which will allow updates beyond the 2.x line. The previous solution was
effectively preventing that with no way for the user to change that.

Issue #19300
ljacomet added a commit that referenced this issue Dec 14, 2021
@dhs-rec
Copy link

dhs-rec commented Dec 15, 2021

Can't find a repo for the Gradle build-cache-node, so I report this here: Version 10.1, released Dec. 13th, also still ships with log4j2 2.15.0.

@joschi
Copy link
Contributor

joschi commented Dec 15, 2021

side note - but an interesting feature would be the ability to ensure that certain libraries/versions with vulnerabilities are not a part of the build - and if they are somehow introduced - fail the build.

@ZakTaccardi That's already possible with dependency constraints, see https://blog.gradle.org/log4j-vulnerability and https://threadreaderapp.com/thread/1470845889166159873.html

@ljacomet
Copy link
Member

ljacomet commented Dec 22, 2021

Note that Gradle 7.3.3 will be released with a bump to log4j 2.17.0 - see #19360

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

No branches or pull requests

5 participants