Globalna awaria Windowsa. Microsoft publikuje instrukcję, znamy przyczyny. Czy katastrofie można było zapobiec?

Awaria CrowdStrike - co poszło nie tak?

O zasięgu i skutkach wczorajszej awarii napisano bardzo wiele, dziś jednak dysponujemy bardziej szczegółowymi informacjami co do przyczyn. Nad problemem pochylił się Zach Vorhies, były pracownik Google i sygnalista, który stwierdził, że winę za wczorajszą awarię ponosi coś, co programiści systemowi wiedzą od dawna. Mechanizmy bezpieczeństwa pamięci w języku C++, a w zasadzie ich ograniczone działanie wynikające z konieczności stosowania tzw. wskaźników to ogromny problem współczesnego IT.

W jednym z plików konfiguracyjnych sterowników dostarczonych przez CrowdStrike, a wykorzystywanych do analizy behawioralnej dokonywanej w celu zapewnienia cyberbezpieczeństwa, znalazł się wskaźnik na region pamięci 0x9c (lub 156). W dużym uproszczeniu - wskazano (błąd ludzki niewychwycony w testach) niewłaściwy region przestrzeni adresowej pamięci, który jest niedostępny dla jakiegokolwiek programu. Działanie każdego programu, który spróbuje uzyskać dostęp do pamięci zostanie automatycznie zakończone przez Windowsa. A że program działał z najwyższymi uprawnieniami, to mógł dokonywać niemożliwego, co skończyło się pętlą ponownych uruchomień Windowsa o zasięgu globalnym.

Microsoft publikuje oficjalne zalecenia

Dziś dostępne są już oficjalne instrukcje dla administratorów, które pozwalają zarówno na ominięcie problemu, jak i przywrócenie komputerów do sprawności. Nie odbiegają one od zaleceń opublikowanych wczoraj i sprowadzają się do uruchomienia systemu w trybie awaryjnym, a następnie ręcznego usunięcia pliku SYS, w którym niewłaściwie zaadresowano pamięć. Plik ten znajduje się w lokalizacji C:\Windows\System32\drivers\CrowdStrike, a jego nazwa to C-00000291*.sys.

Zobacz: Elon Musk wpłaci miliony dolarów na kampanię prezydencką. Wesprze jednego kandydata

Pod uwagę należy oczywiście wziąć takie czynniki jak szyfrowanie pamięci komputera z użyciem BitLockera. Dlatego na zabezpieczonych w ten sposób maszynach do przejścia w tryb awaryjny konieczne jest wprowadzenie klucza, który uzyskać można - rzecz jasna po wcześniejszym uwierzytelnieniu - pod adresem aka.ms/aadrecoverykey.

Czy można było temu zapobiec?

Chybione akurat w tym przypadku wydają się argumenty, według których gdyby nie praktyki nadużywania pozycji lidera i stosowania mechanizmu vendor lock-in, to do wczorajszego globalnego krachu by nie doszło. Wszak na rynku rozwiązań związanych z cyberbezpieczeństwem panuje duża konkurencja i nikt nie zobowiązał administratorów do korzystania z rozwiązań CrowdStrike i przyznawania im najwyższych, systemowych uprawnień.

Podobne opłakane w skutkach wpadki zdarzały się i będą zdarzać, trudno nawet sobie wyobrazić, w jaki sposób miałyby być zwalczane, skoro zaawansowane oprogramowanie służące do zapewniania cyberbezpieczeństwa działa z najwyższymi uprawnieniami. Można oczywiście mieć pretensje do Microsoftu, że jeden plik może zepsuć cały system operacyjny, ale tu powraca argument o tym, że nie ma przymusu korzystania z usług dostawcy wadliwego pliku. Podobnie jak nie ma przymusu korzystania z wadliwego systemu operacyjnego.

Problem nie wystąpiłby, gdyby nie inherentne problemy oprogramowania napisanego w języku C++. Sam Microsoft ocenił przed laty, że w wyniku wadliwych mechanizmów bezpiecznego zarządzania pamięcią w C i C++ bierze się w Windowsie ok. 70 proc. wszystkich błędów i luk bezpieczeństwa. Dlatego coraz więcej jest zwolenników pisania oprogramowania systemowego w bezpiecznym dla pamięci języku Rust, jednak ilość legacy kodu, który trzeba będzie przepisać z C i C++ jest gigantyczna, co daje nikłe szanse na rychłe wyeliminowanie ryzyka awarii takich jak wczorajsza.