CVE-2022-23630 in Gradle
Summary
by MITRE • 02/10/2022
Gradle is a build tool with a focus on build automation and support for multi-language development. 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. 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. For users who cannot update either do not use `ResolutionStrategy.disableDependencyVerification()` and do not use plugins that use that method to disable dependency verification for a single configuration or make sure resolution of configuration that disable that feature do not happen in builds that resolve configuration where the feature is enabled.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/16/2022
CVE-2022-23630 represents a critical dependency verification bypass vulnerability within the Gradle build automation tool that directly impacts software supply chain security. This vulnerability stems from a flaw in Gradle's dependency verification mechanism where the tool fails to properly validate artifacts when configurations with disabled verification are processed before configurations with enabled verification. The vulnerability is classified under CWE-276 as improper privilege management and aligns with ATT&CK technique T1195.002 for supply chain compromise through malicious dependencies. The issue manifests when Gradle's dependency resolution process encounters multiple configurations within a build where some configurations have dependency verification disabled while others have it enabled. When the configuration with disabled verification is resolved first, Gradle's internal state management incorrectly assumes that common dependencies have already been verified, thereby skipping validation for subsequent configurations that require verification.
The operational impact of this vulnerability is significant as it allows malicious actors to introduce untrusted artifacts into build processes without detection, potentially leading to supply chain attacks where compromised dependencies are silently integrated into software releases. This bypass mechanism specifically affects builds that utilize Gradle's ResolutionStrategy.disableDependencyVerification() method, which is commonly employed by various plugins and build scripts. The vulnerability creates a false sense of security where developers believe their builds are protected by dependency verification when in reality, artifacts from configurations with disabled verification can pollute the build environment. Attackers could exploit this by creating malicious versions of commonly used dependencies that would pass through the verification process undetected, particularly affecting organizations that rely on Gradle for multi-language development projects where dependency verification is enabled for some configurations but disabled for others.
Gradle version 7.4 addressed this vulnerability by implementing a more robust validation approach that ensures artifacts are verified at least once when they appear in configurations with active dependency verification, regardless of the order in which configurations are resolved. This fix aligns with security best practices outlined in NIST SP 800-160 and ISO/IEC 27001 frameworks for secure software development lifecycle processes. Organizations affected by this vulnerability should immediately audit their build configurations to identify any usage of ResolutionStrategy.disableDependencyVerification() and ensure that all configurations either maintain consistent verification policies or that the order of resolution is carefully managed. The recommended mitigation strategies include avoiding the use of disableDependencyVerification() method entirely, identifying and removing plugins that utilize this method, and implementing proper build configuration management that ensures consistent dependency verification policies across all project components. Security teams should also consider implementing additional monitoring and validation processes to detect potential exploitation attempts and establish baseline configurations that enforce dependency verification across all build artifacts.