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 can occur in two ways:

• When signature verification is disabled but your verification metadata contains entries for dependencies that only have a gpg element but no checksum element.
• When signature verification is enabled, your verification metadata contains entries for dependencies with a gpg element but there is no signature file on the remote repository.

In both cases, the verification will accept the dependency, skipping signature verification and not complaining that the dependency has no checksum entry.

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.5 patches this issue by making sure to run checksum verification if signature verification cannot be completed, whatever the reason.

Workarounds

• Remove all gpg elements from dependency verification metadata if you disable signature validation.
• Do not add gpg entries for dependencies that do not have signature files.

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.