GH Actions - Cache Poisoning
Aby uzyskać więcej szczegółów, sprawdź oryginalny post https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
Akcja Git action/cache wprowadza mechanizm cache'owania w procesie Continuous Integration (CI), obejmując dwa kluczowe etapy:
Run Action: Ten etap polega na wyszukiwaniu i pobieraniu danych z cache podczas uruchamiania CI. Wyszukiwanie wykorzystuje unikalny klucz cache, co prowadzi do dwóch wyników:
Cache-hit: Żądane dane znajdują się w cache i są pobierane do natychmiastowego użycia.
Cache-miss: Nie znaleziono pasujących danych w cache, co skutkuje świeżym pobraniem wymaganych plików i katalogów, podobnie jak w przypadku pierwszego żądania.
Post Workflow Action: Ten etap jest poświęcony cache'owaniu danych po workflow CI. W szczególności, jeśli wystąpi cache-miss podczas akcji uruchamiania, bieżący stan określonych katalogów jest cache'owany przy użyciu podanego klucza. Proces ten jest zautomatyzowany i nie wymaga jawnego wywołania.
Środki bezpieczeństwa: Izolacja cache i ograniczenia dostępu
Aby utrzymać bezpieczeństwo i zapewnić izolację cache, wprowadza się ograniczenia dostępu, tworząc logiczne oddzielenie między różnymi gałęziami. Na przykład, cache utworzony dla gałęzi Feature-A (z bazą w gałęzi głównej) będzie niedostępny dla pull requesta dla gałęzi Feature-B (również opartej na gałęzi głównej).
Akcja cache przestrzega określonego porządku wyszukiwania:
Najpierw szuka trafień cache w tej samej gałęzi, co uruchomienie workflow.
Jeśli to się nie powiedzie, rozszerza wyszukiwanie na gałąź nadrzędną i inne gałęzie upstream.
Co ważne, dostęp do cache jest ograniczony do gałęzi, rozciągając się na wszystkie workflow i uruchomienia konkretnej gałęzi. Dodatkowo, GitHub wprowadza politykę tylko do odczytu dla wpisów cache po ich utworzeniu, zabraniając jakichkolwiek modyfikacji.
Rzeczywiste implikacje: Od ataku na workflow o niskich uprawnieniach do wysokich uprawnień
Ilustrujący scenariusz CI pokazuje, jak atakujący może wykorzystać cache poisoning do eskalacji uprawnień z workflow o niskich uprawnieniach do workflow o wysokich uprawnieniach:
Workflow Unit-test, odpowiedzialny za uruchamianie testów jednostkowych i narzędzi do pokrycia kodu, zakłada użycie skompromitowanego lub podatnego narzędzia. Ten workflow wykorzystuje akcję Git action/cache, co sprawia, że cache jest dostępny dla każdego workflow.
Workflow Release, odpowiedzialny za budowanie i wydawanie artefaktu aplikacji, optymalizuje swoje operacje, cache'ując zależności Golang.
W tym scenariuszu workflow testów jednostkowych wprowadza złośliwy wpis cache, zastępując legalną bibliotekę logowania Golang (`go
Last updated
