CVE-2021-29428
WysokieCVSS 8.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 44 - wyżej niż 44% wszystkich znanych CVE
Streszczenie
W Gradle przed wersją 7.0, na systemach typu Unix, systemowy katalog tymczasowy może być tworzony z otwartymi uprawnieniami, co pozwala wielu użytkownikom na tworzenie i usuwanie w nim plików. Kompilacje Gradle mogą być podatne na lokalną eskalację uprawnień przez atakującego, który szybko usuwa i odtwarza pliki w systemowym katalogu tymczasowym. Podatność dotyczy kompilacji używających prekompilowanych skryptów w Kotlin DSL oraz testów dla wtyczek Gradle napisanych przy użyciu ProjectBuilder lub TestKit. Jeśli używasz systemu Windows lub nowoczesnych wersji macOS, nie jesteś podatny. Jeśli używasz systemu Unix-like z ustawionym bitem "sticky" na systemowym katalogu tymczasowym, nie jesteś podatny. Problem został naprawiony i wydany w Gradle 7.0. Jako obejście, na systemach Unix-like, upewnij się, że bit "sticky" jest ustawiony. To pozwala tylko oryginalnemu użytkownikowi (lub rootowi) na usunięcie pliku. Jeśli nie możesz zmienić uprawnień systemowego katalogu tymczasowego, możesz przenieść katalog tymczasowy Javy, ustawiając właściwość systemową `java.io.tmpdir`. Nowa ścieżka musi ograniczać uprawnienia tylko do użytkownika budującego. Szczegóły w referencyjnym poradniku bezpieczeństwa GitHub.
Ocena ryzyka
Podatność może umożliwić lokalnemu atakującemu eskalację uprawnień, co może prowadzić do przejęcia kontroli nad procesem budowania i potencjalnie całym systemem.
Rekomendacja
Zaleca się aktualizację Gradle do wersji 7.0 lub nowszej. Jeśli nie można, upewnij się, że bit "sticky" jest ustawiony na systemowym katalogu tymczasowym lub zmień ścieżkę katalogu tymczasowego Javy z ograniczonymi uprawnieniami.
Inne podatności w Gradle
Zobacz wszystkie- CVE-2016-6199Krytyczne
W pliku ObjectSocketWrapper.java w Gradle 2.12 występuje podatność, która pozwala zdalnym atakującym na wykonanie dowolnego kodu poprzez odpowiednio skonstruowany obiekt serializowany.
- CVE-2023-44387Niskie
Podatność w narzędziu Gradle podczas kopiowania lub archiwizacji plików symlinkowanych. Gradle rozwiązuje symlink, ale stosuje uprawnienia samego symlinka zamiast uprawnień pliku docelowego, co prowadzi do zbyt wysokich uprawnień plików wynikowych. Poprawiono w wersjach 7.6.3 i 8.4 oraz nowszych.
- CVE-2023-35947Średnie
Gradle ma podatność na przejście ścieżki podczas rozpakowywania archiwów Tar, co może prowadzić do nadpisania ważnych plików w lokalizacjach, gdzie proces Gradle ma uprawnienia do zapisu. Atakujący może wykorzystać tę lukę, kontrolując źródło archiwum lub modyfikując proces budowy, aby współdziałał z złośliwym archiwum.
- CVE-2023-35946Średnie
Gradle, narzędzie do automatyzacji budowy, ma podatność, która pozwala na zapisanie plików w niezamierzonym miejscu w systemie plików poprzez specjalnie skonstruowane koordynaty zależności. Może to prowadzić do zanieczyszczenia pamięci podręcznej zależności lub nadpisania ważnych plików.
- CVE-2021-32751Wysokie
Gradle przed wersją 7.2 zawiera podatność na zdalne wykonanie kodu w skryptach startowych generowanych przez plugin `application` oraz w skrypcie `gradlew`. Atakujący, który może zmienić zmienne środowiskowe użytkownika uruchamiającego skrypt, może doprowadzić do wykonania dowolnego kodu. Problem został naprawiony w Gradle 7.2 poprzez usunięcie użycia `eval` i wymuszenie użycia powłoki `bash`.
- CVE-2021-29429Średnie
W Gradle przed wersją 7.0 pliki tworzone z otwartymi uprawnieniami w systemowym katalogu tymczasowym mogą pozwolić atakującemu na dostęp do informacji pobranych przez Gradle. Niektóre kompilacje mogą być podatne na lokalne ujawnienie informacji, ponieważ pliki pobierane przez TextResourceFactory trafiają najpierw do systemowego katalogu tymczasowego. Jeśli nie używasz API TextResourceFactory, nie jesteś podatny.
Oryginalny opis (angielski, źródło NVD)
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.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS