CVE-2023-35947
MediumCVSS 6.9Exploitation Probability (EPSS)
Low risk45th percentile - higher than 45% of all known CVEs
Summary
Gradle has a path traversal vulnerability when unpacking Tar archives, which may lead to overwriting important files in locations where the Gradle process has write permissions. An attacker can exploit this flaw by controlling the source of an archive or modifying the build to interact with a malicious archive.
Risk Assessment
This vulnerability may lead to the disclosure of information from sensitive files and overwriting critical data, posing a significant risk to the organization's security. If an attacker controls a remote Gradle build cache server, they could inject malicious entries, further increasing the risk.
Recommendation
It is recommended to upgrade to Gradle versions 7.6.2 or 8.2, which contain fixes for this vulnerability. Additionally, ensure that only trusted parties have write access to the remote build cache and that connections are properly secured.
Other vulnerabilities in Gradle
See all- CVE-2016-6199Critical
The ObjectSocketWrapper.java in Gradle 2.12 has a vulnerability that allows remote attackers to execute arbitrary code via a crafted serialized object.
- CVE-2023-44387Low
Vulnerability in Gradle when copying or archiving symlinked files. Gradle resolves the symlink but applies the permissions of the symlink itself instead of the linked file, resulting in files having too many permissions. Fixed in versions 7.6.3, 8.4 and above.
- CVE-2023-35946Medium
Gradle, a build automation tool, has a vulnerability that allows files to be written to unintended locations in the filesystem through specially crafted dependency coordinates. This could lead to poisoning the dependency cache or overwriting important files.
- CVE-2021-32751High
Gradle before version 7.2 contains a vulnerability to arbitrary code execution in start scripts generated by the `application` plugin and in the `gradlew` script. An attacker who can change environment variables for the user running the script can cause arbitrary code execution. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell.
- CVE-2021-29428High
In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory.
- CVE-2021-29429Medium
In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure, as remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. If you do not use the TextResourceFactory API, you are not vulnerable.
Original NVD description (English source)
Gradle is a build tool with a focus on build automation and support for multi-language development. In affected versions when unpacking Tar archives, Gradle did not check that files could be written outside of the unpack location. This could lead to important files being overwritten anywhere the Gradle process has write permissions. For a build reading Tar entries from a Tar archive, this issue could allow Gradle to disclose information from sensitive files through an arbitrary file read. To exploit this behavior, an attacker needs to either control the source of an archive already used by the build or modify the build to interact with a malicious archive. It is unlikely that this would go unnoticed. A fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Starting from these versions, Gradle will refuse to handle Tar archives which contain path traversal elements in a Tar entry name. Users are advised to upgrade. There are no known workarounds for this vulnerability. ### Impact This is a path traversal vulnerability when Gradle deals with Tar archives, often referenced as TarSlip, a variant of ZipSlip. * When unpacking Tar archives, Gradle did not check that files could be written outside of the unpack location. This could lead to important files being overwritten anywhere the Gradle process has write permissions. * For a build reading Tar entries from a Tar archive, this issue could allow Gradle to disclose information from sensitive files through an arbitrary file read. To exploit this behavior, an attacker needs to either control the source of an archive already used by the build or modify the build to interact with a malicious archive. It is unlikely that this would go unnoticed. Gradle uses Tar archives for its [Build Cache](https://docs.gradle.org/current/userguide/build_cache.html). These archives are safe when created by Gradle. But if an attacker had control of a remote build cache server, they could inject malicious build cache entries that leverage this vulnerability. This attack vector could also be exploited if a man-in-the-middle can be performed between the remote cache and the build. ### Patches A fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Starting from these versions, Gradle will refuse to handle Tar archives which contain path traversal elements in a Tar entry name. It is recommended that users upgrade to a patched version. ### Workarounds There is no workaround. * If your build deals with Tar archives that you do not fully trust, you need to inspect them to confirm they do not attempt to leverage this vulnerability. * If you use the Gradle remote build cache, make sure only trusted parties have write access to it and that connections to the remote cache are properly secured. ### References * [CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) * [Gradle Build Cache](https://docs.gradle.org/current/userguide/build_cache.html) * [ZipSlip](https://security.snyk.io/research/zip-slip-vulnerability)
Vulnerability data from NVD (NIST) · CISA KEV · EPSS