Long story short, Crowdstrike miał swojego regexa (tak, regexa), którym coś tam sobie definiował. Na końcu regexa był wildcard, więc ostatni, dwudziesty pierwszy parametr się zawsze matchował. Problem w tym, że Crowdstrike usunął tego wildcarda i ostatni parametr przestał się matchować. No tylko, że kod nadal go oczekiwał. Programiści aż tacy głupi nie byli i dodali checka na NULL pointera. Ale ten feralny argument nie był ustawiony na NULLa, tylko na losową wartość. Więc kaboom.
Używanie regexów w kernelu moim zdaniem jest wątpliwe moralnie. Ale to nie to było bezpośrednią przyczyną problemu. Po prostu ktoś na ślepo założył, że wszystkie parametry zawsze będą się matchować. Dodatkowo, moim zdaniem pośrednio z raportu wynika, że Crowdstrike nie testował swojego softu z prawdziwymi produkcyjnymi plikami konfiguracyjnymi.
#programowanie #programista15k #pracait
@groman43 Mega słabe moim zdaniem, że nie tego nie wyłapali. Jedna rzecz mnie zastanawia, w jakim przypadku ten channel file 291 przechodził bez crasha?
Jak rozumiem, chyba nie wszystkie PCty z crowdstrikiem się wywaliły, bo jak wszystkie to oznaczało by, że oni przez przypadek nie przetestowali tego release'a w żaden sposób.
@Syster No właśnie wydaje mi się, że testowali z inną wersją tego channel file 291. Ale to tylko moje spekulacje.
@groman43 To i tak im gratuluje, testować nie to co leci na deploy
@Syster W fachowym żargonie takie zachowanie nazywa się "mockowaniem". Jak powiesz "testuje zupełnie inną konfigurację, niż produkcyjna", to wszyscy się oburzą. Jak powiesz "zamockowałem konfigurację", to na nikim nie zrobi to wrażenia.
@groman43 - ci co mają wiedzieć to wiedzą - a dla reszty (głównie strony biznesowej) taki żargon ma tylko zaciemniać znaczenie (bo oni o tak niczego nie rozumieją).
@groman43 - głupki nie mieli środowiska odpowiadającemu produkcji bo do tego musieliby mieć całe laboratorium fizycznych maszyn i wirtualek - ale jak widać najpewniej cięli koszty - i teraz się okazało, że cięli tam gdzie nie trzeba (chociaż założę się, że wewnętrznie ktoś ich ostrzegał - tylko zignorowali)
Poza tym chyba nie słyszeli o Canary Release i wypuszczali update od razu dla wszystkich (więc jak się zjebało to u dużej ilości klientów na raz).
Nie chce mi się nawet dochodzić, jak bardzo zjebane mieli procedury (chociaż te może mieli ok na papierze - tylko ich nie przestrzegali) ale takie ich wyjaśnienie tylko świadczy, że nie poczuwają się do odpowiedzialności, więc kij im w oko i niech tracą kontrakty.
@groman43
Zacznijmy od tego, że problem ma charakter wielopoziomowy i dotyczy Microsoftu, Crowdstrike i klientów.
Microsoft, bo dopuszcza third party software w kernelu. Mieli tego nie robić, ale woleli dopuścić to zamiast poprawić swoją architekturę na wzór Apple.
Crowdstrike, bo ewidentnie dali ciała z testami. Bugi się zdarzają i będą zdarzać. I dlatego właśnie testować należy na wystarczająco szerokim zakresie danych.
Klienci, bo używają takiego produktu, bo robia pełny deployment zamiast staggered release. Tak, wiem, Crowdstrike nie wspiera staggered release. Ale to wraca do kroku pierwszego - czemu kupiono produkt, który nie wspiera standardów wdrożeniowych?
@Dzemik_Skrytozerca 1) UE, z powodów nie do końca mi znanych, wymusiła na Microsoft pełny dostęp do kernela dla 3rdparties, zamiast normalnego API.
- Klienci niekoniecznie muszą wiedzieć co to w ogóle jest staggered release. Sprawdzanie czy wszyscy dookoła robią wszystko z ogólnie przyjętymi normami jest po prostu niemożliwe.
@groman43
UE wymaga, by Microsoft nie wprowadzał nieuczciwych praktyk względem konkurencji. Jeśli dobrze pamiętam, chodziło o to, że Defender mógł działać w kernelu, a konkurencja nie. Microsoft zamiast stworzyć równoprawne rozwiązanie dla wszystkich, po prostu wpuścił drivery anytivirow do kernela. Co mogło pójść nie tak, że zapytam retorycznie.
Tu masz pełne omówienie tematu:
Https://www.google.com/amp/s/www.theregister.com/AMP/2024/07/22/windows_crowdstrike_kernel_eu
Jak coś, Apple stworzył coś takiego. A Linux w standardowych dystrybucjach kernela po prostu nie wspiera takiego uprzywilejowania.
Jeśli Twoje IT wpuszcza niesprawdzony soft na serwery, które są mission critical, i jeśli robi to bez możliwości łatwego wycofania, to jest to też po części ich wina. Brałem udział w wielu awariach na pierwszych liniach, i zawsze fakt posiadania planu wycofania był kluczowy.
Zaloguj się aby komentować