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.

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

  - 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-29428)

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-2023:1867-1 advisory.

    - CVE-2021-29428: Fixed a local privilege escalation through system temporary directory. (bsc#1184807)

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
252333	Linux Distros Unpatched Vulnerability : CVE-2021-29428	Nessus	Misc.	Local	high
174428	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : gradle (SUSE-SU-2023:1867-1)	Nessus	SuSE Local Security Checks	Local	high

Detections

Analytics

CVE-2021-29428

high

Tenable Plugins

high

high