Microsoft släpper återställningsfix för Crowdstrike

Bra summerat men jag tycker inte anvaret för problemet ligger på Crowdstrike.
Det är förstås deras fel att deras produkt kraschade denna gången, men detta hände även för 10 år sedan.

Om några år kan exakt samma fel hända igen, säg med Symantecs produkt. Variabeln i nyheten är Crowdstrike, konstanten är Windows.

Crowdstrike har förstås 0% möjlighet att förhindra Symantec från att orsaka samma fel som Crowdstrike. Microsoft har däremot 100% möjlighet att förhindra det.

Med det resonemanget är det alltså 100% Microsofts ansvar.

Jag vet inte om jag missuppfattat situationen, men som jag förstått det så är det:

• Crowdstrike-mjukvaran kommer med en signerad drivrutin som är buggig, men buggarna hade fram tills nyligen inte märkts.

• De levererar en ny "content"-uppdatering (typ "virusdefinitioner" vad det verkar) med en fil som är felformaterad/innehåller felaktig data.

• En bugg i drivrutinen triggas.

• BSOD.

Jag menar det faktum att det "inte märkts" är dålig certifiering, som utförs av Microsoft enligt Microsofts föreskrifter.

En enskild bugg dyker ju upp då och då. Certifieringsprocesser skall vara utformade för att fånga dessa. Denna bug (krasch) var så uppenbar att den mest rudimentära certifieringen hade upptäckt den. Dålig certifiering är dålig kvalitet hela tiden.

Det är min uppfattning av situationen också, kort sagt var det ett sätt för ovaliderad kod från internet att exekveras i kontexten av en signerad drivrutin.

Det i sig är illa nog, men det blev ytterligare problematiskt när drivrutinen i fråga registrerades som en "boot start driver", vilket innebär att windows ser den som nödvändig för att kunna boota.

Att detta är dåligt verkar ändå uppenbart för alla med lite koll så jag tror MS kommer göra någon form av insats för att blocka det framöver. Om inte tekniskt i windows så åtminstone policymässigt, exempelvis att de inte ger WHQL-cert till drivrutiner som har funktioner för autouppdatering.

Last known good skulle boota med skyddet i samma state som det var förra gången, tex genom att ha bootfiler på ett filsystem med cow-snapshots. Ändringar skrivs som en diff som kan slopas om man behöver göra en rollback. I detta fallet hade man bootat utan att ha de senaste sys-filerna från Crowdstrike, inte utan crowdstrike.

Om den mekanismen kan manipuleras av en angripare är man redan ägd, är man orolig för det borde man vara än mer orolig för att skyddet man valt är kasst. Som det visade sig vara i fredags.

Absolut, poängen i det jag säger är bara att det är lösbart på många sätt.

Visst kan man klanta sig och skapa nya problem vad man än gör men tänker man så gör man ju aldrig någonting. Vilket också skapar problem.

I fredags fick vi ju reda på att riskmedvetenhet hos diverse bolag ledde till att de installerade en mjukvara som kör ovaliderad kod från internet i kernelmode på servern. Ibland blir det inte som man tänkt sig.

Men det går ändå att lösa problem, man får inte ge upp. Se bara vad Apple gjorde med APFS. En miljard enheter, iphones, ipads, appletvs, etc fick ett helt nytt filsystem med stöd för cow, snapshots mm och ingen normal användare märkte något när det hände. Det kunde gått hur illa som helst men det funkade fint.

De gjorde det dessutom utan att en incident som Crowdstrike visade hela världen att något måste göras.

Jag är faktiskt benägen att hålla med här.
Om man under cert-processen märker att mjukvaran läser in filer som kan uppdateras, så hade en av dom första grejorna jag testat varit att slänga dit en ”trasig” fil.

Hur man inte har märkt att det inte finns något skydd mot detta är under all kritik.

Problemet är att MS drog ReFS ur utvecklarnas händer innan den var klart för att desperat visa Enterprise-kunderna för Big Data att man hade en filsystem som inte slog i NTFS fragmenteringsgräns.

Och då kom det inte med för system-OS viktiga funktioner där den viktigaste och mest fatala bristen för windows skall kunna fungera var att den inte har stöd för hårda länkar ala. Posix-style, det är mycket annat som också är bristfälligt och ReFS är idag i stort sett bara en big-storage-filsystem som tas till när NTFS inte längre räckte till - det är också därför som den har i princip stoppats tillbaka till garderoben igen och bara fins på windowsserver-nivå - i alla fall för att kunna skapa nya ReFS-filsystem medans användning och läsning gick att köra på win-pro om jag mins rätt.

NTFS själv har ingen COW-struktur utan det försöker man emulera i ett mjukvarulager med VSS/shadowcopy där systemet arbetar mot en virtuell lager av filsystem som ligger ovanpå NTFS genom VSS som sedan alla filacess-API:er går igenom, men detta är inget som är igång i samband med i tidiga steg i en bootprocess och knappt lämnat UEFI-steget utan i stort sett hela windows måste vara igång när detta är aktivt.

---

I slutändan med all lappande och lagande är att MS verkligen behöver titta på en modernt system-filsystem - men man kan inte göra som med ReFS utvecklarteam att man slänger uppgiften på en undersysselsatt programmerargrupp utan erfarenhet av filsystembyggande och design och säger till dem att gör något som liknar BTRFS men inte så mycket att det kan anklagas för plaigat - och just det - tidplanen och milstolparna är absolut viktigaste att följa!!, mer än kvalitén på koden och funktionalitet så länge skrivna filerna inte längre begränsas av antalet fragment!!, för detta måste levereras inom xx-månader !!!

(har läste blogg från en utvecklare som var med i den teamet - kan inte har varit rolig alls att bli forcerad in i något som är långt utanför gruppens kompentens-zon och ingen ledare/designer som verkligen förstår filsystem och vad som är viktigt där och vilka misstags som gjorts tidigare och helst inte skall upprepas, och framförallt grovt underskatta i tiden det tar innan man har en bra och stabil filsystem som tål stress utan katastrofala haverier)