Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 782694 (CVE-2021-29427, CVE-2021-29428, CVE-2021-29429, CVE-2021-32751) - dev-java/gradle-bin: multiple vulnerabilities (CVE-2021-{29427,29428,29429,32751})
Summary: dev-java/gradle-bin: multiple vulnerabilities (CVE-2021-{29427,29428,29429,32...
Status: CONFIRMED
Alias: CVE-2021-29427, CVE-2021-29428, CVE-2021-29429, CVE-2021-32751
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal trivial (vote)
Assignee: Gentoo Security
URL: https://github.com/gradle/gradle/secu...
Whiteboard: ~4 [ebuild]
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-13 17:48 UTC by John Helmert III
Modified: 2021-07-29 18:11 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Helmert III gentoo-dev Security 2021-04-13 17:48:10 UTC
CVE-2021-29429:

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. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, 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.


Fixed in 7.0, please bump.
Comment 1 Florian Schmaus gentoo-dev 2021-04-16 15:30:50 UTC
Gradle 7 is in ::java. We currently have gradle 6.3 in ::gentoo, but no consumer (nothing in ::gentoo depends on dev-java/gradle). Furthermore, gradle 7 removed support for some deprecated directives. This means that, even if we had gradle 7 in ::gentoo, and even if we had a consumer in ::gentoo, then we probably would still need a gradle version < 7 in ::gentoo to compile the consumer.

But this is all hypothetical. I would be fine with removing gradle from ::gentoo for now. Or to provide a PR for adding gradle 7 to gentoo.
Comment 2 John Helmert III gentoo-dev Security 2021-04-18 00:10:48 UTC
CVE-2021-29427:

In Gradle from version 5.1 and before version 7.0 there is a vulnerability which can lead to information disclosure and/or dependency poisoning. Repository content filtering is a security control Gradle introduced to help users specify what repositories are used to resolve specific dependencies. This feature was introduced in the wake of the "A Confusing Dependency" blog post. In some cases, Gradle may ignore content filters and search all repositories for dependencies. This only occurs when repository content filtering is used from within a `pluginManagement` block in a settings file. This may change how dependencies are resolved for Gradle plugins and build scripts. For builds that are vulnerable, there are two risks: 1) Information disclosure: Gradle could make dependency requests to repositories outside your organization and leak internal package identifiers. 2) Dependency poisoning/Dependency confusion: Gradle could download a malicious binary from a repository outside your organization due to name squatting. For a full example and more details refer to the referenced GitHub Security Advisory. The problem has been patched and released with Gradle 7.0. Users relying on this feature should upgrade their build as soon as possible. As a workaround, users may use a company repository which has the right rules for fetching packages from public repositories, or use project level repository content filtering, inside `buildscript.repositories`. This option is available since Gradle 5.1 when the feature was introduced.
Comment 3 John Helmert III gentoo-dev Security 2021-04-18 00:14:25 UTC
Another, sorry for the noise everyone.

CVE-2021-29428:

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.
Comment 4 John Helmert III gentoo-dev Security 2021-07-21 16:59:31 UTC
CVE-2021-32751:

Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the `application` plugin and the `gradlew` script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use `gradlew` on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes `gradlew`. If one is unable to upgrade to Gradle 7.2, one may generate a new `gradlew` script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of `eval` or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command.
Comment 5 NATTkA bot gentoo-dev 2021-07-29 17:23:10 UTC Comment hidden (obsolete)
Comment 6 NATTkA bot gentoo-dev 2021-07-29 17:31:30 UTC Comment hidden (obsolete)
Comment 7 NATTkA bot gentoo-dev 2021-07-29 17:39:27 UTC Comment hidden (obsolete)
Comment 8 NATTkA bot gentoo-dev 2021-07-29 17:47:38 UTC Comment hidden (obsolete)
Comment 9 NATTkA bot gentoo-dev 2021-07-29 18:03:34 UTC Comment hidden (obsolete)
Comment 10 NATTkA bot gentoo-dev 2021-07-29 18:11:52 UTC
Package list is empty or all packages have requested keywords.