CVE-2022-24329: JetBrains Kotlin Dependency Lock Flaw

CVE-2022-24329 Overview

CVE-2022-24329 is a vulnerability in JetBrains Kotlin before version 1.6.0 that prevents the locking of dependencies for Multiplatform Gradle Projects. This design flaw exposes applications to potential supply chain attacks by allowing unverified or modified dependencies to be introduced during the build process. Without dependency locking, projects cannot guarantee reproducible builds and may inadvertently pull in compromised library versions.

Critical Impact

This vulnerability undermines the integrity of the software supply chain by preventing dependency version verification in Kotlin Multiplatform projects, potentially allowing attackers to inject malicious code through dependency manipulation.

Affected Products

• JetBrains Kotlin (versions prior to 1.6.0)
• Oracle Communications Cloud Native Core Binding Support Function 22.1.3
• Oracle Communications Pricing Design Center 12.0.0.4 and 12.0.0.5

Discovery Timeline

• 2022-02-08 - JetBrains published security bulletin addressing Q4 2021 vulnerabilities
• 2022-02-25 - CVE CVE-2022-24329 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-24329

Vulnerability Analysis

This vulnerability is classified under CWE-829 (Inclusion of Functionality from Untrusted Control Sphere). The core issue lies in the Kotlin Multiplatform Gradle plugin's inability to lock dependency versions, which is a fundamental security control for build reproducibility and supply chain integrity.

In properly secured build environments, dependency locking ensures that specific versions of libraries are used consistently across builds, preventing automatic upgrades that could introduce vulnerable or malicious code. The absence of this functionality in affected Kotlin versions means that Multiplatform Gradle Projects could inadvertently resolve to different dependency versions than intended, opening a vector for dependency confusion attacks.

The vulnerability is exploitable over the network without requiring authentication or user interaction, though the impact is limited to integrity concerns rather than confidentiality or availability compromises.

Root Cause

The root cause stems from the Kotlin Multiplatform Gradle plugin's architecture, which did not implement dependency locking functionality for multiplatform projects. While standard Gradle projects could leverage dependency locking features, the multiplatform plugin lacked the necessary integration to support this security mechanism.

This architectural gap meant that developers working on Kotlin Multiplatform projects had no native way to ensure their dependency resolutions remained consistent and tamper-proof across different build executions or development environments.

Attack Vector

An attacker could exploit this vulnerability through several supply chain attack scenarios:

1. Dependency Confusion: Publishing a malicious package with the same name as an internal dependency to a public repository, potentially causing the build system to resolve the malicious version.

2. Version Hijacking: If an attacker gains access to a public repository or can perform a man-in-the-middle attack on the dependency resolution process, they could inject compromised versions of legitimate dependencies.

3. Transitive Dependency Manipulation: Attackers could target transitive dependencies that are less scrutinized, introducing malicious code through indirect dependency paths.

The vulnerability requires no special privileges or user interaction to exploit, making it particularly concerning for automated CI/CD pipelines that automatically resolve dependencies during builds.

Detection Methods for CVE-2022-24329

Indicators of Compromise

• Unexpected changes in resolved dependency versions between builds
• Build artifacts containing libraries not explicitly declared in project configurations
• Gradle resolution logs showing dependencies resolved from unexpected repositories
• Hash mismatches when comparing build outputs across different environments

Detection Strategies

• Implement build verification systems that compare resolved dependency trees against known-good baselines
• Enable verbose Gradle logging to capture dependency resolution details for security auditing
• Use software composition analysis (SCA) tools to monitor dependency changes in Kotlin Multiplatform projects
• Configure repository monitoring to detect suspicious package publications matching internal dependency names

Monitoring Recommendations

• Regularly audit Gradle dependency resolution logs in CI/CD pipelines for anomalies
• Implement integrity checking for all resolved dependencies using checksums or signatures
• Monitor public package repositories for packages that could be used in dependency confusion attacks against your organization
• Set up alerts for any dependency version changes in Multiplatform Gradle Projects

How to Mitigate CVE-2022-24329

Immediate Actions Required

• Upgrade JetBrains Kotlin to version 1.6.0 or later immediately
• Audit all Multiplatform Gradle Projects for unexpected dependency versions
• Implement manual dependency verification processes until upgrade is complete
• Review recent builds for signs of dependency tampering or unexpected library inclusions

Patch Information

JetBrains addressed this vulnerability in Kotlin version 1.6.0 by implementing dependency locking support for Multiplatform Gradle Projects. The fix was announced in the JetBrains Security Bulletin Q4 2021.

For Oracle products that bundle affected Kotlin versions, Oracle released patches through their Critical Patch Updates. Refer to the Oracle Critical Patch Update April 2022 and Oracle Critical Patch Update July 2022 for specific remediation guidance.

Workarounds

• Manually verify and document all dependency versions used in Multiplatform projects before each build
• Implement repository filtering in Gradle to restrict dependency sources to trusted repositories only
• Use dependency verification features available in Gradle to check checksums of resolved artifacts
• Consider implementing a local artifact repository to cache and verify all dependencies before use

# Example: Enable Gradle dependency verification in gradle/verification-metadata.xml
# This provides additional integrity checking as a compensating control
gradle --write-verification-metadata sha256 help

# Lock dependencies manually by documenting resolved versions
./gradlew dependencies --write-locks

# Configure trusted repositories only in settings.gradle.kts
# repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)