Podatności BuildKit

Złośliwy frontend może przesłać definicję LLB, która powoduje panikę i zakończenie działania buildkitd, przerywając wszystkie buildy uruchomione na tym demonie.

Gdy włączone jest proxy sieciowe z wstrzykiwaniem CA, proces budowania może zmodyfikować własny pakiet CA przed fazą czyszczenia. Może to spowodować zablokowanie czyszczenia, działanie poza głównym systemem plików budowania lub niepowodzenie bez oznaczenia budowania jako nieudane.

Podatność nieprawidłowej walidacji określonej ilości w danych wejściowych w VillaTheme BuildKit – Product Builder for WooCommerce – Custom PC Builder woo-product-builder umożliwia manipulację danymi wejściowymi. Problem dotyczy BuildKit – Product Builder for WooCommerce – Custom PC Builder: od n/a do 1.0.28.

Frontend Dockerfile ładował pliki Dockerfile i .dockerignore do pamięci bez limitu rozmiaru. Kontekst budowania zawierający zbyt duży plik mógł spowodować alokację pamięci proporcjonalną do rozmiaru pliku, co mogło wyczerpać pamięć i zakończyć działanie demona buildkitd, przerywając inne budowania.

Złośliwy frontend może przesłać definicję LLB, która powoduje panikę i zakończenie działania buildkitd, przerywając wszystkie budowania na tym demonie.

BuildKit może zostać oszukany, aby wykonywać operacje na plikach ze specjalnymi i-węzłami tam, gdzie oczekiwane są zwykłe pliki. Specjalne pliki mogą blokować operacje lub, na workerach z uprawnieniami roota, umożliwić nieautoryzowany dostęp do urządzeń hosta.

Złośliwy zewnętrzny frontend BuildKit może wysyłać żądania przy użyciu wewnętrznego API, które mogą stworzyć warunki do wyścigu danych, powodując panikę demona BuildKit.

Złośliwy obraz może reklamować DiffID z innego obrazu, zawierając jednocześnie inną zawartość warstw. W dotkniętych wersjach BuildKit mógł używać reklamowanych DiffID do wyprowadzania tożsamości pamięci podręcznej i snapshotów bez weryfikacji, czy odpowiadają one rzeczywistej zawartości warstw. Jeśli demon BuildKit ze wspólną lub trwałą pamięcią podręczną najpierw przetworzy taki złośliwy obraz, późniejsza kompilacja z użyciem obrazu ofiary może zamontować zawartość warstw kontrolowanych przez atakującego jako obraz bazowy. Może to pozwolić na uruchomienie kodu ze złośliwego obrazu w kompilacji ofiary, na przykład przez zastąpienie często wykonywanej ścieżki, takiej jak /bin/sh. Kod kontrolowany przez atakującego może odczytać sekrety budowania zamontowane w kompilacji, uzyskać dostęp do innych zasobów budowania, zmienić artefakty wyjściowe lub zawiesić kompilację. Problem dotyczy zarówno zwykłych snapshotterów, jak i snapshotterów z leniwym pobieraniem, takich jak stargz.

Nieuwierzytelniony atakujący kontrolujący rejestr lub źródło blobów OCI-layout może dostarczyć zawartość blobów niezgodną z zadeklarowanym skrótem. Wynikowy snapshot może zostać zapisany w pamięci podręcznej pod tym skrótem i wykorzystany przez późniejsze budowanie ofiary, naruszając integralność danych wejściowych budowania.

Jeśli demon BuildKit zostanie uruchomiony z opcją --cdi-disabled, może to doprowadzić do paniki demona, gdy kompilacje próbują użyć urządzeń CDI. Może się to zdarzyć celowo lub przypadkowo.

Wtyczka WordPress BuildKit w wersji przed 1.0.29 nie sanityzuje i nie escapuje prawidłowo danych przesyłanych przez użytkowników z poziomem współpracownika przed ich zapisaniem i późniejszym użyciem w zapytaniu SQL. Umożliwia to współpracownikowi wstrzyknięcie SQL, który zostanie wykonany na bazie danych, gdy wynikowa treść zostanie opublikowana i wyświetlona przez dowolnego nieuwierzytelnionego odwiedzającego.

BuildKit to zestaw narzędzi do konwersji kodu źródłowego na artefakty budowania w wydajny, ekspresyjny i powtarzalny sposób. Przed wersją 0.31.2 niestandardowy klient może wysłać żądanie uploadu do demona BuildKit, które umożliwia plikom ucieczkę z katalogu stanu kontrolowanego przez BuildKit. Klient musi mieć ważne uprawnienia dostępu do API kontroli BuildKit, aby inicjować budowanie, np. ominąć uwierzytelnianie. Problem został naprawiony w wersji 0.31.2.

BuildKit to zestaw narzędzi do konwersji kodu źródłowego na artefakty budowania. Przed wersją 0.31.1 BuildKit czytał kontrolowane przez atakującego pliki /etc/passwd i /etc/group bez górnego limitu podczas rozwiązywania nazwy użytkownika na identyfikator użytkownika lub grupy w executor/oci/user.go i solver/llbsolver/ops/user_linux.go. Złośliwy obraz bazowy lub build może dostarczyć nadmiernie duże pliki, które wyczerpują pamięć podczas rozwiązywania użytkownika i powodują zakończenie procesu buildkitd z powodu braku pamięci.

BuildKit, narzędzie do budowania artefaktów, przed wersją 0.31.1 zawiera podatność, w której niestandardowy frontend może umieścić nieprawidłową wartość SecurityMode w spreparowanym żądaniu budowy. Executor traktuje tę wartość jako tryb bez sandboxa, nie wymagając uprawnienia security.insecure, co wyłącza ochronę Seccomp i AppArmor dla kontenera budowy, mimo że ograniczenia Linux capabilities pozostają.

Podatność w BuildKit umożliwia złośliwemu źródłu Git, przy ustawieniu git.checkoutbundle=true, wykonanie spreparowanego polecenia na hoście podczas pobierania kodu.

Złośliwy klient lub frontend BuildKit może wysłać spreparowane żądanie, które powoduje awarię demona BuildKit z paniką.

W BuildKit, spreparowana wiadomość w niskopoziomowym API budowania może zostać użyta do usunięcia zawartości katalogu /tmp. Akcja, która normalnie służy do usuwania plików wewnątrz kontenera budowania, może uciec do rzeczywistego katalogu tymczasowego hosta.

Podatność w BuildKit. Niestandardowy klient może wysłać żądanie uploadu, które pozwala na ucieczkę plików poza katalog stanu kontrolowany przez BuildKit. Wymaga to ważnych uprawnień dostępu do API kontroli BuildKit.

BuildKit na Windows Container on Windows (WCOW) nie wykrywa katalogowych dowiązań NTFS (junction points) umieszczonych wewnątrz katalogu cache. Niezaufany użytkownik budujący obraz na skonfigurowanym dla WCOW demonie BuildKit może odczytać dowolne pliki hosta dostępne dla procesu demona.

BuildKit w wersjach przed 0.28.1 ma niewystarczającą walidację komponentu subdir w fragmentach URL Git, co może pozwolić na dostęp do plików poza katalogiem głównym sklonowanego repozytorium Git. Dostęp jest ograniczony do plików w tym samym zamontowanym systemie plików.