Odkryto informacje o lukach w obsługach GitHub Actions, które są automatycznie wywoływane przy wysyłaniu pull-requestów do repozytorium pakietów Nixpkgs, używanego w dystrybucji NixOS oraz w ekosystemie związanym z menedżerem pakietów Nix. Luka umożliwiała osobom trzecim wyciągnięcie tokena, który zapewniał dostęp do odczytu i zapisu kodu źródłowego wszystkich pakietów umieszczonych w Nixpkgs. Token ten pozwalał na bezpośrednie wprowadzanie zmian w dowolnym pakiecie za pomocą repozytorium Git projektu, omijając procesy weryfikacji i recenzji zmian.
Możliwość skompromitowania Nixpkgs i podstawienia własnego kodu w dowolnym pakiecie została zademonstrowana przez badaczy bezpieczeństwa w październiku ubiegłego roku na konferencji NixCon i natychmiast została usunięta w infrastrukturze projektu. Niemniej jednak szczegóły przeprowadzonego ataku ujawniono dopiero po roku. Problem był związany z wykorzystaniem w repozytorium GitHub Nixpkgs obsług GitHub Actions, powiązanych z wydarzeniem „pull_request_target” i wykonujących zautomatyzowane kontrole przy przyjmowaniu nowych pull-requestów.
W przeciwieństwie do zdarzenia „pull_request”, w „pull_request_target” obsługom przyznawany jest dostęp do zapisu i odczytu środowiska budowania, co wymaga szczególnej uwagi podczas pracy z danymi przekazywanymi w pull-requestach. W jednej z powiązanych z „pull_request_target” obsług przeprowadzano weryfikację podanego w pull-requestcie pliku „OWNERS”, do czego zbierano i wywoływano narzędzie codeowners-validator: steps: — uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf with: ref: refs/pull/$/merge path: pr — run: nix-build base/ci -A codeownersValidator — run: result/bin/codeowners-validator env: OWNERS_FILE: pr/ci/OWNERS
Problem polegał na tym, że w przypadku błędu formatowania pliku OWNERS narzędzie codeowners-validator wypisywało zawartość niepoprawnie sformatowanej linii w standardowym logu, dostępnym publicznie. Atak polegał na umieszczeniu w pull-requestcie symboliczną linku o nazwie OWNERS, wskazującą na plik „.credentials”, w którym w środowisku budowania umieszczane są dane uwierzytelniające. W związku z tym przetwarzanie tego pliku doprowadziło do błędu i wyświetlenia w publicznym logu pierwszej linii zawierającej token dostępu do repozytorium.
Ponadto odkryto kolejną podatność w obsłudze, która wykonuje sprawdzanie zasad editorconfig. kroki: — nazwa: Pobierz listę zmienionych plików z PR uruchom: gh api […] | jq [ … ] > „$HOME/changed_files” — używa: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 z: ref: refs/pull/$/merge — nazwa: Sprawdzanie pliku EditorConfig uruchom: cat „$HOME/changed_files” | xargs -r editorconfig-checker
W tym przypadku problem polegał na użyciu narzędzia „xargs” do uruchomienia programu editorconfig-checker dla każdego pliku z pull requesta. Skoro nazwy plików nie były weryfikowane pod kątem poprawności, atakujący mógł umieścić w pull request cień z nazwą zawierającą znaki specjalne, które byłyby przetwarzane podczas uruchamiania narzędzia editorconfig-checker jako argumenty wiersza poleceń. Na przykład, przy tworzeniu pliku „—help” narzędzie editorconfig-checker wyświetliłoby pomoc dotyczącą dostępnych opcji.
Źródło: opennet.ru
