Impact

Dependency verification is a security feature in Gradle Build Tool that was introduced to allow validation of external dependencies either through their checksum or cryptographic signatures.

In some cases, Gradle may skip that verification and accept a dependency that would otherwise fail the build as an untrusted external artifact.

This occurs when dependency verification is disabled on one or more configurations and those configurations have common dependencies with other configurations that have dependency verification enabled. If the configuration that has dependency verification disabled is resolved first, Gradle does not verify the common dependencies for the configuration that has dependency verification enabled.

For builds that are vulnerable, there are two risks:

• Dependency poisoning/Dependency confusion: Gradle could download a malicious binary from a repository outside your organization due to name squatting.
• Man In The Middle: If you are still using HTTP only and not HTTPS for downloading dependencies, your build could download a malicious library instead of the expected one.

Patches

Gradle 7.4 fixes that issue by validating artifacts at least once if they are present in a resolved configuration that has dependency verification active.

Workarounds

• Do not use ResolutionStrategy.disableDependencyVerification() and do not use plugins that use that method to disable dependency verification for a single configuration.
• Make sure resolution of configuration that disable that feature do not happen in builds that resolve configuration where the feature is enabled.

References

• CWE-829: Inclusion of Functionality from Untrusted Control Sphere
• A Confusing Dependency
• Dependency Confusion

Questions?

• For security related issues, please email us at security@gradle.com.
• For non-security related issues, please open an issue on GitHub.