[Bugs] [Bug 13524] New: [CVE 21] gradle 4.4.1 CVEs found

Ср Авг 23 23:19:34 MSK 2023

https://bugzilla.rosalinux.ru/show_bug.cgi?id=13524

          Platform: 2021.1
            Bug ID: 13524
           Summary: [CVE 21] gradle 4.4.1  CVEs found
    Classification: ROSA-based products
           Product: ROSA Fresh
           Version: All
          Hardware: All
               URL: CVE-2019-15052, CVE-2019-16370, CVE-2020-11979,
                    CVE-2021-29428, CVE-2021-29429, CVE-2021-32751,
                    CVE-2023-35946, CVE-2023-35947,
                OS: Linux
            Status: CONFIRMED
          Severity: normal
          Priority: Normal
         Component: System (kernel, glibc, systemd, bash, PAM...)
          Assignee: bugs на lists.rosalinux.ru
          Reporter: y.tumanov на rosalinux.ru
        QA Contact: bugs на lists.rosalinux.ru
                CC: e.kosachev на rosalinux.ru, s.matveev на rosalinux.ru,
                    y.tumanov на rosalinux.ru
  Target Milestone: ---
             Flags: secteam_verified?

Please patch CVEs for package gradle version 4.4.1

INFO (CVEs are): gradle 4.4.1
 cves found
CVE-2019-15052
Desc: The HTTP client in Gradle before 5.6 sends authentication credentials
originally destined for the configured host. If that host returns a 30x
redirect, Gradle also sends those credentials to all subsequent hosts that the
request redirects to. This is similar to CVE-2018-1000007.
Link: https://nvd.nist.gov/vuln/detail/CVE-2019-15052
Severity: CRITICAL
CVE-2019-16370
Desc: The PGP signing plugin in Gradle before 6.0 relies on the SHA-1
algorithm, which might allow an attacker to replace an artifact with a
different one that has the same SHA-1 message digest, a related issue to
CVE-2005-4900.
Link: https://nvd.nist.gov/vuln/detail/CVE-2019-16370
Severity: MEDIUM
CVE-2020-11979
Desc: As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the permissions
of temporary files it created so that only the current user was allowed to
access them. Unfortunately the fixcrlf task deleted the temporary file and
created a new one without said protection, effectively nullifying the effort.
This would still allow an attacker to inject modified source files into the
build process.
Link: https://nvd.nist.gov/vuln/detail/CVE-2020-11979
Severity: HIGH
CVE-2021-29428
Desc: 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.
Link: https://nvd.nist.gov/vuln/detail/CVE-2021-29428
Severity: HIGH
CVE-2021-29429
Desc: 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.
Link: https://nvd.nist.gov/vuln/detail/CVE-2021-29429
Severity: MEDIUM
CVE-2021-32751
Desc: 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.
Link: https://nvd.nist.gov/vuln/detail/CVE-2021-32751
Severity: HIGH
CVE-2023-35946
Desc: Gradle is a build tool with a focus on build automation and support for
multi-language development. When Gradle writes a dependency into its dependency
cache, it uses the dependency's coordinates to compute a file location. With
specially crafted dependency coordinates, Gradle can be made to write files
into an unintended location. The file may be written outside the dependency
cache or over another file in the dependency cache. This vulnerability could be
used to poison the dependency cache or overwrite important files elsewhere on
the filesystem where the Gradle process has write permissions. Exploiting this
vulnerability requires an attacker to have control over a dependency repository
used by the Gradle build or have the ability to modify the build's
configuration. 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. Gradle
will refuse to cache dependencies that have path traversal elements in their
dependency coordinates. It is recommended that users upgrade to a patched
version. If you are unable to upgrade to Gradle 7.6.2 or 8.2, `dependency
verification` will make this vulnerability more difficult to exploit.
Link: https://nvd.nist.gov/vuln/detail/CVE-2023-35946
Severity: MEDIUM
CVE-2023-35947
Desc: 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)

Link: https://nvd.nist.gov/vuln/detail/CVE-2023-35947
Severity: HIGH

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://lists.rosalinux.ru/pipermail/bugs/attachments/20230823/2c55c573/attachment.html>