Według komunikatu CERT Polska z 30 kwietnia 2026 r. podatność Copy Fail w systemach Linux umożliwia lokalną eskalację uprawnień do root. Komunikat wyróżnia jako szczególnie narażone m.in. środowiska multi-tenant, kontenery i CI runners, czyli miejsca, gdzie jeden system obsługuje wielu użytkowników albo wykonuje cudzy kod. Dla firm, które tak pracują, izolacja kont i kontenerów jest warta tyle, ile odporność wspólnej warstwy pod nimi.

Wyobraź sobie biurowiec, w którym każdy najemca ma własne drzwi z własnym zamkiem, a w portierni wisi jeden klucz generalny do wszystkich pięter. Najemcy porównują zamki, wymieniają je na lepsze i czują się bezpiecznie. Rzadko który pyta, jak trudno osobie z przepustką gościa dojść do tego klucza. Lokalna eskalacja uprawnień do root jest taką ścieżką od przepustki do portierni: zaczyna się od zwykłego konta w systemie, a kończy na pełnej władzy nad maszyną. Na serwerze, który obsługuje jedną aplikację jednego zespołu, skutki zostają w rękach tego samego właściciela. Na hoście, gdzie jedno jądro Linuksa dzielą konta wielu klientów, kontenery i zadania CI, ten sam klucz otwiera wszystkie drzwi naraz. O tym drugim przypadku jest ta analiza komunikatu CERT Polska.

Copy Fail prowadzi od zwykłego konta do uprawnień root

Jak podaje CERT Polska w komunikacie o podatności Copy Fail, luka pozwala na lokalną eskalację uprawnień do root. Oba słowa mają tu znaczenie. „Lokalna” oznacza, że atakujący musi najpierw móc coś uruchomić w systemie: mieć na nim konto, proces w kontenerze albo zadanie w potoku CI. „Root” to cel: konto, które w Linuksie kontroluje cały system, łącznie z plikami i procesami pozostałych użytkowników.

Na hoście współdzielonym ta para słów nabiera wagi. Konta i kontenery wyglądają z perspektywy aplikacji jak osobne pomieszczenia, ale stoją na jednym jądrze Linuksa, które pilnuje podziału między nimi. Kto zdobędzie uprawnienia root na takim hoście, może sięgnąć poza granice własnej usługi, do usług sąsiadów.

Ten tekst nie wchodzi w szczegóły techniczne Copy Fail. Zajmujemy się tym, co taka podatność oznacza dla architektury, w której wiele usług dzieli jedno jądro.

Granica między usługami na jednym hoście jest tak mocna, jak jądro, które jej pilnuje.

Słowo „lokalna” uspokaja tam, gdzie cudzy kod uruchamia się z założenia

Załóżmy, że procedura oceny podatności w firmie obniża priorytet lukom z dopiskiem „wymaga dostępu lokalnego”. Rozumowanie jest wygodne. Najpierw ktoś musiałby wejść do środka, a przed tym chronią uwierzytelnianie, zapora i segmentacja sieci. W trzech z wyróżnionych przez CERT Polska środowisk ten warunek jest spełniony z założenia.

Runner CI istnieje po to, żeby wykonywać kod z repozytorium. Platforma multi-tenant obsługuje wielu klientów na wspólnej infrastrukturze. Kontenery pozwalają uruchamiać na jednym hoście aplikacje różnych zespołów lub klientów. W każdym z tych przypadków organizacja sama daje możliwość uruchomienia kodu, więc warunek „dostępu lokalnego” spełnia każdy, kto ma zwykłe konto klienta albo prawo do uruchomienia zadania.

Rozjazd między dokumentem a praktyką łatwo pokazać na hipotetycznym przykładzie. Opis platformy CI mówi „zadania izolowane w kontenerach”. Runner obsługujący zadania z repozytoriów otwartych dla zewnętrznych współpracowników działa na tym samym hoście co zadania wdrażające system produkcyjny. Na papierze izolacja istnieje i nikt nie skłamał. Wobec lokalnej eskalacji do root oba zadania dzielą jednak jedno jądro, a z nim jedną granicę bezpieczeństwa.

Tam, gdzie uruchamianie cudzego kodu jest funkcją usługi, dopisek „wymaga dostępu lokalnego” przestaje być powodem do odłożenia aktualizacji.

Jeden host to wspólne ryzyko kilku właścicieli

Dla zarządu sprawa sprowadza się do dwóch pytań: ile usług dzieli jedno jądro i kto odpowiada za jego aktualizację. Odpowiedź wymaga trzech rzeczy: mapy współdzielonych zasobów, okna aktualizacji i sprawdzenia izolacji po zmianie.

Mapa pokazuje, które usługi, dane i zespoły stoją na każdym hoście z cudzym kodem. Bez niej ocena ryzyka Copy Fail kończy się na liście serwerów i pomija to, co na nich sąsiaduje. Okno aktualizacji trzeba uzgodnić ze wszystkimi właścicielami usług na hoście, bo zmiana we wspólnej warstwie dotyczy ich jednocześnie. Sprawdzenie izolacji zamyka sprawę dowodem: które hosty objęto, kto to potwierdził i na jakiej podstawie.

Odpowiedzialność rozkłada się różnie. Jądro hosta, którym administruje własny zespół, aktualizuje własny zespół. Przy hostingu współdzielonym albo runnerach CI dostarczanych jako usługa jądro należy do dostawcy. Firma go nie zaktualizuje, ale może zapytać o stan względem komunikatu CERT Polska z 30 kwietnia i zapisać odpowiedź przy usłudze. Kosztu prac żaden komunikat za firmę nie policzy: zależy od liczby hostów i liczby usług na każdym z nich.

Komunikat polskiego CSIRT z 30 kwietnia daje wspólny punkt odniesienia

Komunikat opublikował CERT Polska, więc polskie organizacje mają oficjalny tekst krajowego CSIRT po polsku i w otwartym dostępie. Dziś, pięć dni po jego publikacji, piszemy o skutkach dla architektury współdzielonej; nowego alarmu ten tekst nie ogłasza.

W rozmowie z dostawcą hostingu, platformy CI czy usługi kontenerowej ten komunikat jest wygodnym wspólnym odniesieniem. Nazwa Copy Fail, data 30 kwietnia i adres na moje.cert.pl pozwalają zadać jedno pytanie wszystkim dostawcom i porównać odpowiedzi. Dostawca, który odpowie ogólnikiem „aktualizujemy na bieżąco”, nie odpowiedział na pytanie o konkretny host i konkretną usługę.

Mówimy o pojedynczej podatności. Z jednego komunikatu nie wyprowadzimy skali zagrożenia dla polskich firm ani nie ogłosimy fali ataków. Wystarczy on natomiast, żeby sprawdzić, które własne usługi zależą od jądra dostawcy albo dzielą jądro z cudzym kodem.

Co z tym zrobić w poniedziałek

Każdy punkt zmieści się w 30 minutach. Celem jest ustalenie, gdzie wspólne jądro łączy usługi i kto za nie odpowiada; zakres prac technicznych wyznaczą odpowiedzi.

  1. Spisz hosty, na których działa cudzy kod. Zacznij od runnerów CI i serwerów obsługujących wielu klientów lub użytkowników, potem dopisz hosty z kontenerami. Przy każdym zapisz, jakie inne usługi dzielą z nim jądro i kto jest jego właścicielem.
  2. Wyślij właścicielom i dostawcom jedno pytanie o Copy Fail. Dołącz link do komunikatu CERT Polska z 30 kwietnia i poproś o stan każdego hosta oraz termin okna aktualizacji. Odpowiedź bez wskazania konkretnego hosta oznacz jako nieustaloną.
  3. Zapisz, gdzie izolacja jest granicą bezpieczeństwa. W rejestrze ryzyka wskaż hosty, na których rozdzielenie kont lub kontenerów chroni usługi różnych klientów albo oddziela zadania z cudzym kodem od zadań produkcyjnych. Dla każdego ustal, kto i na jakiej podstawie potwierdzi stan hosta po aktualizacji.

Copy Fail przypomina, że izolacja kont i kontenerów na jednym hoście zależy od warstwy, którą wszystkie usługi dzielą. Firma, która uruchamia cudzy kod, powinna znać listę usług stojących na wspólnym jądrze, zanim tę listę sprawdzi ktoś z dostępem do zwykłego konta. Mapa hostów i odpowiedź dostawcy przypisana do konkretnej usługi są lepszym dowodem bezpieczeństwa niż słowo „izolowane” w dokumentacji.

Źródła

  1. CERT Polska: Podatność „Copy Fail” w systemach Linux umożliwia lokalną eskalację uprawnień do root, publikacja: 30 kwietnia 2026.

Redakcja cyberinsight.pl.