Žel, tak to dopadá, když se na software spěchá a odflákne se testování. Obávám se, že tady ani použití bezpečnějších jazyků není zárukou, že se to nebude opakovat.
Ony ty bezpečnější jazyky nejsou rozhodně všelék - a nemělo by se na to zapomínat.
Ale to není ani to zpomalení distribuce - já za tím tuším snahu stihnout distribuční okno
a tlak na urychlené dodání. (Ne, že bych to neznal z práce...) Pak se spousta testů udělá formálně, nebo se prostě nestihne.
Jen doufám, že ten problém, který to mělo řešit, alespoň stál za to,
V době, kdy na elektronických systémech závisí velmi závažné činnosti jako řízení letového provozu nebo nemocnice, by mělo být hlavním zájmem udržet systém co nejbezpečnější ale také v provozu.
Takže místo těžko představitelného scénáře "přeskočit chybně fungující komponentu" bych očekával využití už existujícího (byť nefunkčního) přístupu revertnutí změn zmršené aktualizace do posledně známé funkční konfigurace po opakovaném neúspěšném bootu.
Pokud už se oháníme jménem Anatolije Ďatlova, tak by stálo za úvahu, že shození řídícího systému jaderné elektrárny do bluescreenu a nemožnost elektrárnu řídit by jistě byla větší problém, než revertnutí nefunkční aktualizace. Ale co chtít v systému, který mi je schopný psát 15 minut v kuse "Vyčkejte, vše pro vás připravujeme" místo toho, aby dal uživateli informaci, že už 15 minut visí na stále nepřicházející odezvě ze sítě...
Jinak tedy souhlasím, že ta neustálá hektičnost a nesmyslně urychlená komunikace a zkratkovitá řešení nás pozvolna ničí. Ale zrovna v tomto případě ta zkratkovitost nespočívá v tom, že by mělo být ok nechat pár dní čekat tisíce lidí na letištích a ve špitálech, ale v tom, že kontrola aktualizace měla dostat svůj čas. Ono jak se ukazuje, ti potenciální útočníci si vždycky najdou kreativně nějaký způsob, jak situace zneužít. Na Rootu psali moc zajímavou informaci, kolik podvodných domén s "řešením" problému stihlo vzniknout včetně toho, že útočníci v latinské americe pod záminkou zasílání opravy šířili malware...
Protože je to aktualizace reagující na nově objevenou bezpečnostní hrozbu. Řešení jako ta od firmy CrowdStrike si firmy pořizují i proto, aby dokázala rychle reagovat na aktuální hrozby. Firmy si to nepořizují proto, aby pak slyšely: „Ano, útočník prošel přes naše bezpečnostní řešení. Ano, o tomto typu útoku jsme věděli a uměli jsme ho detekovat. Bohužel jste zrovna byly v kontrolní skupině.“
Nemyslím si, že se v tomto případě půjde cestou zpomalení distribuce. Spíš se zavedou další nástroje na kontrolu kódu, možná přepis do bezpečnějších jazyků tam, kde to jde. Protože v tomto případě údajně ta nová data způsobila dereferencování nulového ukazatele v C++ kódu.
Je pěkné, že si CrowdStrike sype popel na hlavu, ale reakce Microsoftu ve stylu "my za nic nemůžeme" by si myslím zasloužila podstatně víc pozornosti.
Je evidentně něco zásadně koncepčně špatně v architektuře operačního systému, který lze shodit aktualizací aplikace v user-space, tím spíš, když problém údajně nezpůsoboval ani driver. K čemu je pak dobrá obnova systému, když nedokáže takový problém vyřešit...
Rozhodně je to do budoucna velmi zajímavý vektor útoku na infrastrukturu.
Tohle nebylo instalováno jako driver. Sice to má příponu sys, ale není to driver. Oni tomu říkají „konfigurační soubor“, tj. je to právě taková vylepšená databáze signatur – soubor s daty, kterými se řídí ten bezpečnostní engine. Ta chyba v ovladači, který zkolaboval na špatných datech, tam klidně mohla být už dlouho. Akorát teď se jim poprvé povedlo uvolnit soubor s daty, který tu chybu (někdy) způsobil.
Z vyjadreni Crowdstrike je patrno, ze se (navzdory pripone) nebavime o kernelovem driveru. Z tehoz vyjadreni je patrne, ze nic jineho nez ten channel file (na ktery lze pohlizet asi jako na nejake signatury) poruseny nebyl. Ano, je relevantni diskutovat o tom, jak si samotny Crowdstrike resi kontolu integrity podobnych veci, se kterymi pracuji.
Skoro to vypada na takovou tu "klasiku", kdy se na podobne veci v ramci vseobjimajiciho "spechu" kasle - podobne funkce uzivatel typicky nevidi, takze nemivaji z pohledu vyvoje moc prioritu. A takove "nedodelky" se daji najit na mnoha mistech.
Připomenulo mi obdobný update ve firmě manželky. Zálohovací systém po nějakém update byl přepnut do test-režimu (simulace). Systém data načítal, ale neukládal na záložní médium. Přišlo se náhodou, když potřebovali obnovit nějaký soubor a zjistili, že poslední skutečná záloha byla stará několik měsíců a ne několik hodin. :-(
21. 7. 2024, 17:33 editováno autorem komentáře
Vsak letadla kvuli Crowdstrike nepadala ani kvuli tomu nevybouchnul zadny reaktor, ze? ;-) Ve skutecnosti se stalo par neprijemnosti z kategorie "no boze, zitra je taky den". Ano, clovek by asi nechtel byt v te dobe na letisti, na druhou stranu tam se dejou i horsi veci... staci blby overbooking, ze? Ve finale tam zkejstete zrovnatak.
Nemyslím si, že šlo o nějaké stihnutí distribučního okna. Tohle se aktualizuje několikrát denně. Bezpečnější jazyk samozřejmě není zárukou, že nedojde k žádné chybě. Ale zrovna tomu dereferencování nulového ukazatele by jiný jazyk zabránil. To testování bylo víc odfláknuté v době, kdy vznikl ten kód, než teď, kdy vznikla konfigurace, na které spadl.
Jaderná elektrárna je projektovaná tak, aby výpadek řídícího systému vede do bezpečného stavu, i za cenu zastavení výroby elektřiny. Tedy přesně to, co psal Danny – raději bezpečnost než za každou cenu zachovat nebezpečný provoz. Navíc ten hlavní řídící systém elektrárny asi nebude jeden, ale bude tam stejný záložní, který se neaktualizuje hned spolu s hlavním. A věci podstatné pro bezpečnost elektrárny se dají řídit i bez toho řídícího systému.
Revertnutí změn po nepovedené aktualizaci v tomhle případě také nebude triviální. Aktualizován byl běžný datový soubor. Asi byste nechtěl, aby vám návrat k předchozímu stavu systému smazal i všechna uživatelská data. Takže by to znamenalo, že by běžná aplikace v uživatelském prostoru musela umět zaregistrovat některé soubory, že jsou součástí systémových snapshotů. Navíc takové snapshoty by vznikaly několikrát denně – je otázka, zda je na to systém systémových snapshotů Windows stavěn.
Řešitelné to je, ale dosud asi nikdo neměl takovou potřebu – zejména když tu potřebu mají externí firmy, ale naimplementovat to musí Microsoft.
A co se týče kontroly aktualizace – pořád zapomínáte na to, že je to aktualizace definic bezpečnostního softwaru. Každá minuta zdržení znamená, že někde projde útok, který už umíte zastavit. To neznamená, že se má nová verze vyrolovat ven za každou cenu bez otestování – ale váš přístup, že vůbec neberete ohled na čas, je opačný extrém.
Ono jak se ukazuje, ti potenciální útočníci si vždycky najdou kreativně nějaký způsob, jak situace zneužít. Na Rootu psali moc zajímavou informaci, kolik podvodných domén s "řešením" problému stihlo vzniknout včetně toho, že útočníci v latinské americe pod záminkou zasílání opravy šířili malware...
Tohle ale není argument proti aktualizacím. Tohle je argument jenom pro potřebu vzdělávání lidí ohledně práce s informacemi. Útočníci si vždycky najdou nějakou záminku. A třeba sopkám, zemětřesení, tornádům, erupcím na Slunci a dalším přírodním jevům asi těžko budete vysvětlovat, že musí myslet na to, že jejich akce může být záminkou pro podvodníky.
Klidně to může být problém nedostatečně definovaného, dokumentovaného a/nebo testovaného rozhraní. Autor kódu nepředpokládal, že by v datech nějaký objekt nemusel být, a autor dat neměl čím vhodným objekt naplnit, tak ho tam prostě nedal. A asi neexistuje žádný validátor, který zkontroloval, že je ten datový soubor vytvořen správně, a nevaliduje to ani interpret. Nebo ten validátor existuje, ale chová se jinak, než skutečný interpret.
MS je akcionar CS, tedy ulickou si saha na penize ktere by mu radovi uzivatale jeho produktu nedodali. Stejne tak je mozne ze tak jako OPICE ma CS prime volani nedokumentovanych api.
Nicmene je to chyba v definici, ten vlastni sw se nemelil pouze se v definici poprve objevil obsah kterej to "naparsovalo" na nullpointer a smrt. mozna mozna kdyby tu aktualizaci necpali primo tomu sw ale aktualizacnimu agentu (coz nejspis zavedou) co pojede v userspace a pote co potvrdi ze je to ok to teprve zacne system kterej bezi mnohem vyse (nize) uzivat.
konspiracni teorie ze to CS vzalo na sebe samozrejme porad ziji i kdyz jsou hotove debugy a dumpy chovani po prijeti aktualizace ktere jasne ukazuji ze je to chyba v datech. jako fantazijni by bylo kdyby o byl fakt utok tj zacal nekdo hromadne tlacit tu komunikaci ktera vedla k te definici protoze o te chybe vedel, ale to je fakt cista fantasmagorie ale 1% konspiratorum staci.
Tak ono je k diskuzi, zda-li system s nefunkcnim bezpecnostnim prvkem ma "aspon nejak" fungovat... nebo radeji nefungovat vubec. A fakt to neni jen o jedne firme. Tu otazku jde polozit naprosto obecne... ja treba radsi budu chvili doma o svickach, nez abych sazel na kumst a hrdinstvi borcu typu Anatolije Stepanovice Datlova. Ono tech chyb, co uz historicky nasekal lidsky faktor malo fakt neni.
Zajimavy vektor utoku na infrastrukturu by to byl i v pripade, kdyby se chybne fungujici komponenta zcela "preskocila" a nechala system deravy, ze?
Doporučuji shlédnout toto video
https://youtu.be/wAzEJxOo1ts?si=BYQ3SGECSQyBc9BI