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)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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) (CVE-2023-35947)

Note that Nessus relies on the presence of the package as reported by the vendor.

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 / openSUSE 15 host has a package installed that is affected by a vulnerability as referenced in the SUSE-SU-2024:3923-1 advisory.

    - CVE-2023-35947: Fixed an issue while unpacking tar archives, where files could be created outside of the     unpack location (bsc#1212931).

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Type	Severity
259488	Linux Distros Unpatched Vulnerability : CVE-2023-35947	Nessus	Misc.	Local	high
210474	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : gradle (SUSE-SU-2024:3923-1)	Nessus	SuSE Local Security Checks	Local	high

Detections

Analytics

CVE-2023-35947

high

Tenable Plugins

high

high