CVE-2021-29429
ŚrednieCVSS 4.0Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 40 - wyżej niż 40% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Wrażliwe informacje zawarte w pobranych plikach mogą zostać ujawnione innym lokalnym użytkownikom tego samego systemu. Ryzyko dotyczy głównie środowisk wieloużytkownikowych, w których katalog tymczasowy jest współdzielony.
Rekomendacja
Zaktualizuj Gradle do wersji 7.0 lub nowszej, która przenosi użycie katalogu tymczasowego do katalogu Gradle User Home z ograniczonymi uprawnieniami. Alternatywnie ustaw bardziej restrykcyjny umask lub zmień katalog tymczasowy Javy poprzez właściwość systemową java.io.tmpdir.
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-29428Wysokie
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.
Oryginalny opis (angielski, źródło NVD)
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.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS