CERT Polska ostrzegł w czwartek, 7 maja, że podatność Dirty Frag pozwala lokalnemu użytkownikowi systemu Linux uzyskać uprawnienia root, a kod demonstracyjny był już wtedy publicznie dostępny. Dla operatorów serwerów współdzielonych, klastrów i systemów CI, które uruchamiają cudzy kod, to ryzyko całej usługi. Zanim ktokolwiek zacznie łatać, ustalmy, kto za to ryzyko odpowiada.

Zadaj na porannym spotkaniu jedno pytanie: kto odpowiada za system, na którym wspólny runner CI uruchamia kod przesłany z zewnątrz? Zespół aplikacji wskaże infrastrukturę. Infrastruktura wskaże zespół, który zamawiał runnery. Ten z kolei przypomni, że obraz systemu przygotowuje ktoś inny, a aktualizacje „idą automatycznie”. Każda z tych odpowiedzi brzmi rozsądnie i żadna nie wskazuje osoby, która dziś sprawdzi, czy maszyna jest odporna na Dirty Frag. Właśnie takie miejsca CERT Polska wyróżnił w ostrzeżeniu z 7 maja: serwery współdzielone, środowiska wielu klientów, Kubernetes, kontenery i systemy CI wykonujące kod użytkowników. Wspólny mianownik jest prosty. Ktoś spoza zespołu ma tam legalną możliwość uruchomienia własnego kodu, a to wystarcza, by lokalna podatność przestała być lokalnym problemem.

Dirty Frag zamienia lokalne konto w uprawnienia root

Według CERT Polska Dirty Frag umożliwia lokalnemu użytkownikowi systemu Linux uzyskanie uprawnień root. Skrót z tytułu komunikatu, LPE, oznacza lokalną eskalację uprawnień. Atakujący zaczyna od dostępu, który już ma: zwykłego konta na serwerze, powłoki w kontenerze albo zadania uruchomionego w potoku CI. Na końcu tej drogi jest root, czyli najwyższy poziom uprawnień w systemie.

Drugi fakt z ostrzeżenia waży tyle samo: kod demonstracyjny był publicznie dostępny. Publiczny przykład skraca drogę od opisu luki do jej wykorzystania, bo atakujący nie musi sam opracowywać sposobu ataku.

Czego z ostrzeżenia nie da się ustalić? Nie wiadomo, czy Dirty Frag był już wykorzystywany w atakach, ani jaka byłaby skala takich prób. Dirty Frag to przy tym odrębna podatność od opisanej wcześniej luki Copy Fail, więc wymaga osobnego sprawdzenia, nawet jeśli tamtą sprawę zespół już zamknął.

Lokalna eskalacja uprawnień brzmi jak problem kogoś, kto już jest w środku. W usłudze, która uruchamia cudzy kod, w środku są wszyscy klienci.

Na współdzielonym serwerze „lokalny” znaczy „każdy klient”

Jeśli plan łatania ustawia lokalne eskalacje niżej niż luki dostępne z sieci, ma do tego powód. Skoro atakujący musi najpierw mieć konto, to wcześniej musi pokonać inne zabezpieczenia. Na serwerze, do którego logują się wyłącznie własni administratorzy, taka kolejność często się broni.

Lista CERT Polska pokazuje, gdzie ta reguła przestaje działać. Na serwerze współdzielonym konto ma każdy klient. W środowisku wielu klientów obok siebie działają systemy różnych odbiorców. W klastrze Kubernetes i w kontenerach kod różnych zespołów lub klientów może działać na tej samej maszynie. System CI z definicji wykonuje kod, który ktoś mu przysłał. We wszystkich tych przypadkach krok, który procedura uznaje za trudny, należy do normalnego działania usługi. Klient nie musi się włamywać, żeby dostać konto. Dostaje je w umowie, zwykle razem z fakturą.

Druga rozbieżność dotyczy odpowiedzialności. Jeśli runner CI postawił zespół programistów, klaster utrzymuje zespół platformy, a obraz systemu przygotował jeszcze ktoś inny, to każdy z nich może uczciwie uważać, że aktualizacje systemu należą do kogoś innego. Procedura opisuje wtedy właściciela usługi, a ekspozycja na Dirty Frag właściciela nie ma.

Root na wspólnej maszynie to ryzyko całej usługi

Zarządowi przedstawmy jedną tezę. W środowisku, które wykonuje cudzy kod, lokalna eskalacja uprawnień przestaje być sprawą jednego konta. Root na serwerze współdzielonym daje władzę nad wszystkim, co na nim działa, czyli także nad danymi i procesami pozostałych klientów. Skutek dotyka więc usługi jako całości i zaufania wszystkich jej odbiorców naraz.

Dlatego pierwsze pytanie dotyczy właściciela ekspozycji. To osoba, która wie, które systemy wykonują kod spoza firmy, i może zdecydować o oknie serwisowym. Samą aktualizację wykona potem ktoś z zespołu.

Drugie pytanie dotyczy stanu poprawki dla Dirty Frag na 11 maja. Sprawdź go u wydawcy dystrybucji używanej na każdym z systemów i zapisz obok datę sprawdzenia.

Trzecie pytanie dotyczy obejścia tymczasowego. Jeśli zespół wdrożył je zamiast poprawki, ono też potrzebuje właściciela i warunku zakończenia. Bez nich rozwiązanie na kilka dni może przeleżeć w konfiguracji długie miesiące.

Obejście tymczasowe bez właściciela i daty końca staje się stałą konfiguracją, o której nikt już nie pamięta.

Ostrzeżenie CERT Polska z 7 maja jako podstawa decyzji

Polscy operatorzy usług, serwerów współdzielonych i systemów CI nie muszą szukać uzasadnienia dla pilnych prac. CERT Polska skierował ostrzeżenie bezpośrednio do administratorów, nazwał podatność, opisał jej skutek i wyróżnił środowiska szczególnie narażone. To wystarczy, by wpisać sprawę do rejestru ryzyk z datą i odwołaniem do konkretnego dokumentu.

Ostrzeżenie ma przy tym dwie warstwy. Fakty z ostrzeżenia dotyczą podatności: lokalny użytkownik może uzyskać uprawnienia root, kod demonstracyjny był publiczny, a CERT wyróżnił środowiska szczególnie narażone. Nie mówią nic o tym, czy konkretna firma ma takie środowiska ani w jakim są stanie. Tę część firma ustala we własnej infrastrukturze, a także u dostawców, którzy uruchamiają kod firmy na swoich maszynach. Firma bywa przecież także jednym z wielu klientów cudzego serwera lub cudzego systemu CI.

Od ostrzeżenia minęły cztery dni. Przy publicznym kodzie demonstracyjnym brak nazwanego właściciela też jest decyzją, tyle że nikt jej nie zapisał.

Co z tym zrobić w poniedziałek

  1. Spisz systemy, na których działa cudzy kod. Przejdź przez środowiska wyróżnione w ostrzeżeniu CERT Polska: serwery współdzielone, środowiska wielu klientów, Kubernetes, kontenery i systemy CI wykonujące kod użytkowników. Przy każdym systemie wpisz jednego właściciela ekspozycji, także wtedy, gdy maszyną zarządza dostawca.
  2. Sprawdź aktualny status poprawki dla Dirty Frag. Dla każdego systemu z listy ustal u wydawcy dystrybucji albo u dostawcy, czy aktualizacja jest dostępna i czy już działa na tym systemie. Zapisz datę sprawdzenia i odwołanie do komunikatu CERT Polska z 7 maja.
  3. Nadaj obejściu tymczasowemu datę końca. Jeśli zespół zastosował obejście zamiast poprawki, wpisz je do rejestru zmian z właścicielem i warunkiem zamknięcia, którym jest wdrożenie aktualizacji. Wyznacz termin przeglądu, w którym ktoś potwierdzi spełnienie warunku.

W usłudze współdzielonej o wadze lokalnej luki przesądza to, ilu ludzi z zewnątrz ma do niej legalny dostęp. Dirty Frag trafia w środowiska, w których takich ludzi jest najwięcej, więc pierwszym zabezpieczeniem jest nazwisko właściciela przy każdym współdzielonym systemie.

Źródła

Redakcja cyberinsight.pl.