Wprowadzenie do problemu / definicja
W projekcie flyto-core w wersji 2.26.7 ujawniono podatność klasy Arbitrary File Write, która umożliwia zapis plików poza katalogiem izolowanym przewidzianym przez mechanizm sandboxingu. Problem dotyczy operacji eksportu danych do CSV, w których ścieżka docelowa może być kontrolowana przez użytkownika bez skutecznej walidacji względem katalogu roboczego.
W praktyce oznacza to naruszenie granic izolacji systemu plików. Moduł, który powinien zapisywać dane wyłącznie w wyznaczonym obszarze, może tworzyć pliki również w innych lokalizacjach dostępnych dla procesu aplikacji.
W skrócie
- Podatność dotyczy flyto-core do wersji 2.26.7.
- Problem obejmuje moduły
data.csv_writeorazdata.json_to_csv. - Luka pozwala zapisywać pliki poza katalogiem definiowanym przez
FLYTO_SANDBOX_DIR. - Przyczyną jest pominięcie mechanizmu walidacji ścieżek przed wykonaniem operacji zapisu.
- Poprawkę wprowadzono w wersji 2.26.8.
Kontekst / historia
Nowoczesne platformy automatyzacji i przetwarzania danych szeroko korzystają z mechanizmów sandboxingu, aby ograniczać skutki błędów logicznych oraz wymuszać separację dostępu do zasobów. W takim modelu wszystkie operacje odczytu i zapisu powinny być ograniczone do zdefiniowanej przestrzeni roboczej.
Analizowany przypadek pokazuje klasyczny problem niepełnej poprawki bezpieczeństwa. Jeśli jedna część aplikacji zostanie zabezpieczona, ale analogiczne moduły nadal korzystają z niezweryfikowanych ścieżek, to model ochrony pozostaje niespójny. Właśnie takie rozszczelnienie często prowadzi do praktycznych nadużyć w środowiskach produkcyjnych.
Analiza techniczna
Istota problemu sprowadza się do braku wymuszenia wspólnej walidacji ścieżek wyjściowych. Mechanizm ochronny odpowiedzialny za kontrolę, czy ścieżka mieści się w katalogu sandbox, istnieje, ale nie został wykorzystany we wszystkich miejscach odpowiedzialnych za zapis plików.
W efekcie użytkownik może przekazać własną ścieżkę docelową i doprowadzić do utworzenia pliku poza dozwolonym obszarem. To nie jest wyłącznie prosty przypadek manipulacji sekwencjami typu ../, lecz szerszy problem architektoniczny: aplikacja przyjmuje ścieżkę systemową i wykonuje zapis bez centralnie wymuszonej kontroli bezpieczeństwa.
Z technicznego punktu widzenia luka wynika z niespójności implementacyjnej pomiędzy warstwą ochronną a modułami wykonującymi operacje I/O. Tego typu błędy są szczególnie groźne, ponieważ zabezpieczenie formalnie istnieje, co może dawać fałszywe poczucie bezpieczeństwa podczas przeglądu kodu lub testów powierzchownych.
- możliwe jest nadpisanie plików roboczych,
- można tworzyć nieautoryzowane artefakty na hoście,
- dochodzi do obejścia założeń izolacji danych,
- powstaje przestrzeń do dalszej eskalacji skutków incydentu, zależnie od uprawnień procesu.
Konsekwencje / ryzyko
Skala zagrożenia zależy przede wszystkim od tego, z jakimi uprawnieniami działa flyto-core i jakie katalogi są dostępne z poziomu procesu. Sama luka nie musi od razu oznaczać zdalnego wykonania kodu, ale arbitralny zapis plików bardzo często stanowi wartościowy etap pośredni w łańcuchu ataku.
Atakujący może potencjalnie zapisywać pliki konfiguracyjne, modyfikować dane tymczasowe lub generować artefakty w lokalizacjach obserwowanych przez inne komponenty. W środowiskach CI/CD, kontenerach oraz systemach integracyjnych skutki mogą być większe, jeśli współdzielone wolumeny zostały zamontowane zbyt szeroko.
Ryzyko rośnie szczególnie wtedy, gdy aplikacja przetwarza dane pochodzące od użytkowników, zewnętrznych integracji lub automatycznych agentów. W takich scenariuszach możliwość wskazania ścieżki wyjściowej może zostać wykorzystana do trwałej manipulacji środowiskiem pracy.
Rekomendacje
Najważniejszym krokiem jest weryfikacja używanej wersji i aktualizacja do wydania zawierającego poprawkę, czyli co najmniej 2.26.8. Samo wdrożenie nowej wersji powinno jednak zostać uzupełnione o audyt lokalnych rozszerzeń, forków i własnych modułów wykonujących operacje plikowe.
- wymusić centralną walidację wszystkich ścieżek wejściowych i wyjściowych,
- blokować ścieżki bezwzględne oraz wychodzące poza dozwolony katalog,
- uruchamiać proces z minimalnymi uprawnieniami do systemu plików,
- ograniczyć wolumeny współdzielone i montowane katalogi,
- monitorować nietypowe operacje zapisu poza obszarem roboczym,
- dodać testy regresyjne dla wszystkich modułów wykonujących podobne operacje I/O.
Z perspektywy DevSecOps warto projektować interfejsy plikowe tak, aby moduły nie przyjmowały surowych ścieżek systemowych od użytkownika. Bezpieczniejszym podejściem jest stosowanie logicznych identyfikatorów zasobów, które dopiero zaufana warstwa aplikacji mapuje na kontrolowaną lokalizację w systemie plików.
Warto również przeanalizować logi aplikacyjne i systemowe pod kątem nietypowych zapisów plików, zwłaszcza jeśli podatna wersja była używana w procesach automatyzacji danych lub integracjach z mniej zaufanymi źródłami wejściowymi.
Podsumowanie
Podatność Arbitrary File Write w flyto-core 2.26.7 pokazuje, jak niebezpieczne może być częściowe domknięcie problemu bezpieczeństwa. Kluczową słabością okazał się brak spójnego egzekwowania walidacji ścieżek względem katalogu sandbox, co otworzyło drogę do zapisu plików poza przewidzianym obszarem izolacji.
Dla administratorów i zespołów bezpieczeństwa najważniejsze działania to szybka aktualizacja, ograniczenie uprawnień procesu oraz kompleksowy przegląd wszystkich mechanizmów wejścia i wyjścia pod kątem jednolitego egzekwowania kontroli dostępu do systemu plików.
Źródła
- Exploit Database – flyto-core 2.26.7 – Arbitrary File Write — https://www.exploit-db.com/exploits/52655
- GitHub – flyto-core repository — https://github.com/flytohub/flyto-core
- GitHub Security Advisory – GHSA-p34x-fmph-9fjx — https://github.com/Pig-Tail/security-research/tree/master/GHSA-p34x-fmph-9fjx-flyto-core