CrowdStrike publiceert eindrapport onderzoek naar bug achter Windows-storing

De codevalidator die CrowdStrike gebruikte tijdens de grote storing in juli, kon niet goed omgaan met een nieuw templateformaat dat het bedrijf gebruikte. Dat schrijft het bedrijf na zijn onderzoek naar de storing. CrowdStrike zei eerder dat het om een bug in die tool ging.

CrowdStrike heeft het eindrapport met bevindingen op dinsdag vrijgegeven. Dat rapport kijkt naar de oorzaak van een bug die vorige maand voor een wereldwijde storing in Microsoft-computers zorgde. Het bedrijf bracht eind vorige maand een voorlopig rapport uit. Toen schreef het bedrijf dat de fout onder andere zat in 'een bug' in de codecontrolesoftware. In het eindrapport staat dat die bug geen softwarefout was, maar dat de codevalidator niet goed om kon gaan met een nieuwe manier om CrowdStrikes Falcon Sensor te voorzien van up-to-date informatie over bedreigingen.

Zoals CrowdStrike eerder al bescheef, zat het probleem in zogeheten Template Instances en Template Types. Dat zijn modellen waarmee CrowdStrike de Falcon Sensor voedt met informatie. De Sensor draait op endpointapparaten, waardoor die constant nieuwe informatie ontvangen over bedreigingen. In februari van dit jaar bracht CrowdStrike Sensor-versie 7.11 uit, inclusief nieuwe Template Types. Die nieuwe Template Types kunnen apparaten beschermen tegen aanvallen op pipes en interprocess communication in Windows.

De nieuwe Template Types bevatten volgens CrowdStrike 21 inputparametervelden. De eerste nieuwe IPC Template Types die werden uitgebracht, in februari, maart en april, bevatten minder dan twintig velden, maar die van juli had er 21. Het probleem ontstond omdat de code interpreter verwachtte dat er maximaal twintig velden in de template zouden staan. Door het 21ste veld aan te spreken, ontstond een out-of-bounds-memory-read die zorgde voor de blue screens of death op Windows-pc's.

CrowdStrike erkent verder ook dat het proces voor codevalidatie en -testen niet goed op orde was. Het bedrijf zegt dat zowel handmatige als geautomatiseerde testen worden uitgevoerd als het nieuwe templates uitbrengt, maar dat dat vooral gericht was op 'operationele use-cases' en de mate van beveiliging. Het bedrijf zegt dat in een aantal testscenario's niet specifiek werd gekeken naar de out-of-bounds-readfouten die de template had.

CrowdStrike heeft meerdere maatregelen, mitigaties en aanpassingen doorgevoerd in zijn processen en testsoftware. Het bedrijf zegt bijvoorbeeld dat het gefaseerde releases van nieuwe templates gaat uitbrengen. Critici vroegen zich al langer af waarom CrowdStrike dat niet deed. Verder gaat CrowdStrike twee externe bedrijven inschakelen om de Falcon Sensor op securityproblemen te scannen.

Reacties (105)

[CPV]

geen softwarefout was, maar dat de codevalidator niet goed om kon gaan met

Da's dan toch ook gewoon een sotwarefout?

Maar goed, validators, codecheckers en nog meer tools, maar er gaat niets boven een live-test.
Dat zouden zo ook eens moeten doen.

[TijsZonderH]

Hmm ja ik snap nu inderdaad wel hoe je het kan lezen. Wat ik ermee bedoel is: toen CrowdStrike z'n prelim-onderzoek publiceerde hadden ze het expliciet over een bug. Ze impliceerden dat de validator stuk was, dat het iets had moeten doen maar dat dat niet gebeurde omdat er iets verkeerd ging. Maar het blijkt nu dat de validator niet om kon gaan met een anders bestandsformaat. Dat vind ik wel twee verschillende dingen: een bug, versus 'de software kan iets niet'. Dat is wat ik ermee bedoel als ik het zo opschrijf.

[Septillion]

Maar draait die codecontrolesoftware dan in de instance? Dat lijkt me toch eerder iets dat je in dev draait voor een release die moet checken dat het allemaal goed is zodat de release kan plaatsvinden Of mis ik iets?

[Guru Evi]

Het is een array out of bound fout. Als je de hele document leest:

Een van de updates had een verandering geïntroduceerd waar ze de regels (een regex) aanpassen met meer (21) argumenten dan voordien, echter een deel van de engine kon maar 20 regels behandelen. Dus eenmaal de update uitkwam kreeg de code 21 regels en ging die gewoon uitvoeren, echter de 21ste regel ging buiten het geheugen wat tot een BSOD leidde.

Een stapel problemen:
Geen bounds checks en input validatie: dus als je een update file krijgt was er nergens “if args > 20”. Ook nergens een test dat de hele update (die in de kernel draait) kan verwerkt worden alvorens ze te aanvaarden (wat als het opzettelijk corrupt was gemaakt?).
De paar testen die ze deden waren met versies die het probleem niet bevatte.
Ze deden enkel code tests die blijkbaar niet goed geschreven waren
Geen tests van de werkelijke update
Geen canary testing, beta channel testing etc - gewoon, de testen compileren, zend het uit.
Aan de andere kant is het Windows, een programma die out of bounds gaat zou niet zomaar mogen het hele OS crashen (de Linux kernel heeft al lang bescherming voor “stomme bugs”: https://docs.kernel.org/dev-tools/kfence.html)

[Reactie gewijzigd door Guru Evi op 7 augustus 2024 12:18]

[Septillion]

Dank, dat bevestigd het inderdaad. Dan is het dus inderdaad gewoon een "ordinaire" bug die al maanden geleden gemaakt is (maar nog niet getriggerd was). En dus codecontrolesoftware die die fout niet zag. Maar daar de focus op leggen is naar mijn idee dus meer een afleidingstactiek.

Laat onder aan de streep naar mijn idee dus vooral een bedrijfsprobleem zien waarbij volledig vertrouwd is op de codecontrolesoftware. En niet op goede protocollen en meerdere veiligheden.

[Reactie gewijzigd door Septillion op 7 augustus 2024 12:27]

[Guru Evi]

Yep, dat is hoe ik het ook zie, het publiek afleiden met pagina’s aan magie van hun regexp engine en hoe de bug in elkaar steek. Al de testen die ze niet gedaan hebben staan op 2 pagina’s in het 40+ pagina rapport en worden relatief afgewaaid want ze hebben wel code testing - ja maar je hebt de code die je gepubliceerd hebt helemaal niet getest, de code test bevatte geen enkele argument test, je hebt een oude compilatie gebruikt die het probleem niet had om te testen en vervolgens een volledig nieuwe update gewoon naar alle klanten geduwt.

De oplossing is letterlijk een intern beta channel gebruiken en een paar VMs opzetten die de update eerst krijgen, moest je dat gedaan hebben zouden al die VMs platliggen. De oplossing dat ze nu voorschotelen is dat klanten kunnen kiezen of ze de eerste willen zijn voor updates te krijgen.

[Reactie gewijzigd door Guru Evi op 7 augustus 2024 12:30]

[maxxer29]

Duidelijke analyze inderdaad vooral die limiet van 20 en dan 21 van die templates proberen te laden geeft inderdaad een grove fout aan. Stel voor die limiet had wel hoger gestaan dan was er nog ruimte geweest om heel crowdstrike te hacken met templates die juist dingen door laten gaan die niet door de beugel kunnen.
De reden waarom die limiet op 20 stond kon ik niet terug vinden , maar zal een reden voor zijn geweest. Je wil checken hoeveel templates er zijn en hoevel er mogen zijn en zouden moeten zijn.

[Guru Evi]

Als die limiet er was, dan moet de code testing dit toch ook testen:
test1(args[0..19])
test2(args[0..21])
test3([])
test4([0.. sizeof(int)+1]

[TheVivaldi]

Maar een bug ís een softwarefout:

https://www.vandale.nl/gr.../nederlands/betekenis/bug

bug (de; m; meervoud: bugs) fout in een computerprogramma

Maar de vraag is hier: waaróm kon de validator het niet? Was dat ook een bug of simpelweg iets wat (nog) niet geïmplementeerd was?

[Reactie gewijzigd door TheVivaldi op 6 augustus 2024 22:41]

[smartsys]

Mijns inzien heeft niemand bedacht om een validator in de validator in te bouwen. Simpelweg een check of de input file voldoet aan het verplichte formaat. Bij afwijking, sorry het formaat is ongeldig.

Ik vind dit niet echt een bug, tenzij die validator er wel degelijk inzit, maar toch de afwijking niet geconstateerd heeft.

[Webgnome]

Het doet iets wat het niet behoorde te doen ongeacht de gevolgen dan is het een bug.

[smartsys]

Ik zie een bug meer als een situatie waarbij een memory-leak oid optreedt. Een stukje code wat wel doet wat het moet doen, maar wat enkele ongewenste bijverschijnselen laat zien waar de ontwikkelaar geen rekening mee gehouden heeft. Dit soort zaken vallen vaak ook niet op tijdens de test fase en blijkt uit fouten in de praktijk

Een controle slag "vergeten" te programmeren zie ik niet als een bug. Dat is gewoon een FOUT.

[Webgnome]

Dit is dan toch een bug? Immers er worden 21 definities geladen en daar kon de code (array out of bounds) niet tegen. Dat had je moeten testen want ongewenst gedrag -> bug

[Reactie gewijzigd door Webgnome op 8 augustus 2024 09:47]

[smartsys]

Ik denk dat we hier niet uit gaan komen.

Je kunt alles wat niet goed is de kwalificatie "bug" geven, maar je kunt ook onderscheid maken tussen designfouten en programmeer fouten. Een programmeerfout is dan een "bug", maar een designfout niet.

Een template file niet checken op opmaak is naar mijn mening een designfout.

[fRiEtJeSaTe]

Dit is Tweakers op z’n best.
Muggenziften tot het eind. Betweter 1 vs betweter 2.

[TijsZonderH]

Maar hoe zou je het verschil zoals ik dat net noem beschrijven? Welke term past dan beter?

[TheVivaldi]

Zie mijn edit. Ik had niet verwacht dat je (op dit late tijdstip) zo snel zou reageren.

[TijsZonderH]

Ik zit voor BlackHat in Las Vegas dus ik heb net m'n lunch op en ben keihard aan het werk

[TheVivaldi]

O, hahaha, dus een tijdsverschil. Wist niet dat je in nu in het casinoparadijs zat (al zit je er voor andere doeleinden). Dat verklaart het.

[TijsZonderH]

Ik kan je zeggen dat van alle prachtige plekken op deze aardbol Las Vegas voor mij het verst van 'paradijs' af zit... Maar goed, de beurs is interessant en daar gaat het om!

[TheVivaldi]

Ben ik met je eens, hoor. Het is meer dat de meeste mensen het zo noemen. Maar jij en ik duidelijk zijn niet zoals de meesten.

[Devian]

Misschien moeten jullie even samen een hokje opzoeken..

[TheVivaldi]

Met alle respect, maar ik ben hetero.

[garriej]

Het heet dan ook paradise: Wikipedia: Paradise, Nevada Dus niet zo gek dat mensen het zo noemen

[DdeM]

Ik vind het ook nogal een verschil of de software iets niet kan en dus maar niets doet, of dat het iets probeert en vervolgens een BSOD veroorzaakt. Dat tweede is gewoon een bug.

[Reactie gewijzigd door DdeM op 6 augustus 2024 22:24]

[HerrPino]

Dat is wel degelijk een bug. Al was het alleen al dat de validator dat niet signaleerde en blijkbaar vrolijk verder ging.

Als ik een switch schrijf en de op dat moment bekende waarden goed verwerk en bij een onbekende waarde geen exceptie gooi en vrolijk verder ga, met alle gevolgen van dien … dan is dat gewoon een bug.

[Maestro.mosjuh]

Ik doe ook een poging om het te verklaren:

De codevalidator is ontworpen en ontwikkeld om om te gaan met validaties van type f, g en h.
Nu is na afronden van de codevalidator type i er bij gekomen, maar de codevalidator is daar nooit voor gemaakt en valideert type i dus niet.

Is het dan een bug dat hij niet valideert? Een software-ontwikkelaar zou zeggen: dat type toevoegen moet niet door middel van een bugmelding maar door het indienen van een (user)story, want het is nieuw te bouwen functionaliteit....

[DdeM]

Het is niet een bug dat de validator het niet valideert, het is een bug dat de validator compleet over zijn nek gaat en BSOD's veroorzaakt zodra die iets tegenkomt wat die niet kan valideren.

[Maestro.mosjuh]

Nou, zoals ik het lees is het als volgt:
De release was - kunnen we wel concluderen - niet goed getest.

1 van de stappen van de geautomatiseerde testen is de codevalidator - deze codevalidator valideerde type i helemaal niet, waardoor het probleem niet is geconstateerd.

Het is niet perse de codevalidator die de BSOD veroorzaakte...

[Moraxv]

De bug is dan toch meer dat de codevalidator niet terugmeldt dat er een onbekend type aangeboden wordt en dat de aanroepende code dat antwoord niet (goed) interpreteert? Als je type a t/m h verwacht moet je de rest afwijzen.

[bewerkers]

Ik snap het ook niet goed. Lijkt mij dus 2 softwarefouten. 1 buffer overflow bug in de update en 1 bug in de validator.
En los daarvan een fout in de uitrol door niet snel genoeg in te grijpen.

[Zoop]

Inderdaad, lijkt mij op z'n minst meer dan 1 probleem. Dat zo'n validator niet met bepaalde informatie kan omgaan, ala, ik kon er wel inkomen om dat geen bug te noemen maar eerder een missende featureset.

Maar hoe de situatie dan verder afgehandeld wordt dat het in een BSOD resulteert, lijkt mij toch wel een keiharde bug. Idealiter zou hij opmerken dat de validator een fout heeft en dan een rollback doet / opstarten in safemode / simpelweg een bericht geeft, etc, alles behalve een BSOD in ieder geval

[TheVivaldi]

Ja, precies. Fouten kan iedereen maken, maar de afhandeling is een ander verhaal. Een rollback had hier wel moeten plaatsvinden. Liever een definitie missen en daardoor een iets grotere kans op een onveilig systeem, dan de ellende die er nu van kwam. Als ze het na die rollbacks snel hadden aangepakt, hadden ze wellicht later die dag of anders de volgende dag een tweede poging kunnen wagen, waardoor met een onveilig systeem zitten maar van korte duur was geweest. (En daarbij: 100% veiligheid bestaat toch niet.) Alles beter dan de situatie die er nu van kwam, met alle ellende van dien.

[Reactie gewijzigd door TheVivaldi op 7 augustus 2024 11:11]

[Guru Evi]

Het feit dat een BSOD gebeurt is Windows fout. Op alle andere OS zijn hier beschermingen tegen met oa. guard pages tussen alle code, inclusief drivers, echter vanwege compatibiliteit draaien drivers in Windows zonder enige bescherming.

Het grootste probleem van CrowdStrike was het feit dat ze enkel op code tests afgingen alvorens het te publiceren en de testen die ze gedaan hebben waren niet met de “foutieve” channel file. In principe was er geen enkele fout, enkel dat de driver niet overweg kon met nieuwe features.

Als iemand de code tests niet of verkeerd heeft, duwen ze alsnog naar de klant. En hun oplossing is nu om de klant meer opties te geven voor wanneer ze de updates aanvaarden.

Er zijn zoveel dingen die niet gebeuren in hun CI/CD schakels dat ik denk dat ze helemaal geen CI/CD hebben, dat updates gewoon de devs zijn die naar de server kopiëren.

Waar ik werk zijn we ook CrowdStrike klanten maar deze praktijken geven wel meer informatie op onze andere problemen. Oa Opswat integratie die enkel werkt met bepaalde versies en dan breekt in andere, test en QA dacht ik is gewoon niet in orde voor een rare feature, maar blijkbaar volstrekt niet aanwezig in het hele product.

[Reactie gewijzigd door Guru Evi op 7 augustus 2024 12:44]

[kuurtjes]

Ik denk dat het echte verhaal is dat de codevalidator de bug niet had gevonden. Maar dat het gewoon een bug was. Ik denk dat ze het een beetje proberen downplayen.

[imqqmi]

Zo lees ik dat ook. De validator van het model detecteerde niet dat er een extra veld was toegevoegd en de code laadde het model in en verwachtte een 21e veld en dat zit niet in de data > out of bounds memory read.

[SPee]

Of de code laadde het model wel in, maar alleen 20 velden. En de validator wil dan het 21e veld gaan gebruiken en *bam*.

voorbeeldje:

data[] model = new data[21];
fn dostuff() {
readmodel();
validator();
}

fn readmodel() {
for (i =0; i < 21; i++) {
model[i] = sometypevalue;
}
}

fn validator() {
for (i =0; i <= 21; i++) {
model[i].dostuff();
}
}

[Reactie gewijzigd door SPee op 7 augustus 2024 12:23]

[Florimon]

Niet alleen live-testen; they need to eat their own dog food. Dus er moet geen enkele update naar klanten uitgerold worden, voordat deze eerst op de eigen endpoints uitgerold is. En ik heb het dan over echte in gebruik zijnde endpoints, dus bv de Windows laptops/desktops van de eigen developers (niet iedereen gebruikt een Mac). Als dit al wel gebeurde, dan zijn hun eigen endpoints niet representatief voor die van klanten (waarom niet?), als dit nog niet gebeurde, dan dient dezelfde onvermijdelijke vraag zich aan: waarom niet? Is de eigen software niet goed genoeg (om wat voor reden dan ook) voor de eigen systemen?

[CPV]

Mee eens. Het irriteerde me al een beetje, dat iedereen de testtools probeerde uit te leggen, wat ze wel en niet konden en waarom ze wel of niet de oorzaak konden zijn van de problemen.

Mijn punt was dat daarna gewoon een live-test gedaan moet worden. En inderdaad op een representatieve test-farm. Als je ziet wat de gevolgen kunnen zijn, kun je niet voorzichtig genoeg zijn met uitrollen.

[DdeM]

Ja ik zat het ook drie keer te lezen om te vinden waar ze zeggen dat het geen softwarefout is, maar zie het nergens staan. Nee, ik lees juist dat er meerdere software fouten waren in de productiecode (code validator en code interpreter).

[mphilipp]

Het bedrijf zegt dat zowel handmatige als geautomatiseerde testen worden uitgevoerd als het nieuwe templates uitbrengt

Dat doen ze ook. Maar ja...zo gaan die dingen: er wordt iets verandert en ergens in de keten is er iets dat daar niet op rekent. Het is uiteindelijk steeds de mens die de fout maakt. De computer 'is just following orders'. Geen enkel systeem kan dit ondervangen, zolang er mensen tussen zitten om 'domme' dingen te doen. Maar 100% geautomatiseerd is ook weer een dingetje, omdat mensen (daar heb je ze weer) met de software moeten werken, en die doen gekke dingen...kringetje is weer rond.

Kijk maar naar autonoom rijden: dat gaat helemaal goed als alle voertuigen op de weg autonoom rijden en idealiter ook nog eens met elkaar praten over hun intenties enzo. Maar dan heb je nog die vermaledijde voetgangers en fietsers die er zo heerlijk irrationeel tussendoor crossen. Geen computer die daarop kan anticiperen. Dus tot die tijd blijven ongelukken gebeuren.

[Robbierut4]

Uit het artikel:

Het bedrijf zegt bijvoorbeeld dat het gefaseerde releases gaat doen van nieuwe templates. Critici vroegen zich al langer af waarom CrowdStrike dat niet deed.

Achteraf is het makkelijk klagen natuurlijk. Andersom gaan bedrijven ook klagen als ze geïnfecteerd raken door iets wat wel bekend is bij CrowdStrike, maar het bedrijf toevallig in de laatste fase van de release zit.

Zeker omdat een gefaseerde uitrol redelijk wat tijd kost, je moet eerst wachten of je geen feedback krijgt vanuit de eerste groep.

[MennoE]

Uit de tekst die je citeert lijkt te volgen dat de critici hierover al klaagden vooraf dit incident zich voordeed. Dus dan is geen sprake van 'achteraf klagen'.

[the_stickie]

Staggered rollouts zijn sowieso een best practice imho.
Wel is het zo dat ik an sich graag heb dat een AV (of 'endpoint protection tool') snel op de hoogte is van alle bedreigingen (dmv definities/patterns/...). Uiteindelijk zouden die updates impactloos moeten zijn omdat ze geen code vervangen.
Crowdstrike heeft aangetoond dat met definities waarop de engine niet goed voorbereid is, toch gevaarlijk zijn. Ook hebben ze niet enkel definities aangepast, maar functionaliteit toegevoegd om met nieuwe types malware te kunnen omgaan. Dat is iets waar ik als beheerder toch graag (meer) controle over heb.

[ewoutw]

Staggered rollouts zijn sowieso een best practice imho.

hallo 2009 hier, wil graag mijn best practice terug!!!

Als het om security definities gaat (dat ging het hier) wil ik die zo snel mogelijk hebben. Ik zou niet willen dat ik gehackt door een bekent issue met een bekende oplossing. Maar helaas was het punt van binnenkomen morgen pas aan de buurt.

Als het om updates gaat waar functionaliteit wordt aangepast of waar de software zelf wordt aangepast is het nog altijd wel beter om het gefaseerd te doen.

Blijft natuurlijk dat wel dat je als fabrikant wel moet testen. Snap dat het onmogelijk is om alle mengeling hard-en-software configuraties kan testen. Maar in dit geval hadden ze er echt wel achter moeten komen. Hardware en configuratie maakten niet uit.
Ook qua ontwerp van de software mag je vraagtekens zetten. Hoe kan een update van te veel definities een BSoD veroorzaken. Hoezo zit hier geen foutafhandeling op.

[the_stickie]

Nee, dat is net het probleem: het ging niet louter om definities. Het ging om extra functionaliteit om andere types malware te kunnen detecteren.
Staggered wil ook niet zeggen dat het weken moet duren...

[supersnathan94]

Als het om updates gaat waar functionaliteit wordt aangepast

Het toevoegen van nieuwe typen lijkt mij een uitbreiding van de featureset en daarmee aanpassing van de functionaliteit.

Het ging niet om definities an sich maar het toevoegen van een type definities of in dit geval 2 types.

Men had dit kunnen zien bij een “live test” ofwel integratie test op 1 machine, want iedere machine ging plat.

Lijkt mij dan ook dat er nu een dedicated machine komt in de aangepaste test procedure om precies dit nogmaals te voorkomen. Al was het maar een setje VMs. Als 100% faalt dan kun je dat heel snel zien.

hallo 2009 hier, wil graag mijn best practice terug!!!

Hallo 8,5 miljoen machines in 2024 hier. Mogen we em toch nog even lenen?

Staggered kan ook in uren en met een ramp up. Nu was het 8,5 MILJOEN apparaten in een uur. Knap dat ze zo snel kunnen uitrollen, tamelijk vervelend gezien de impact.

[citegrene]

Je windows zero days worden ook pas de 2de dinsdag van de maand gepatched. Genoeg tijd om zelf te testen en een preview rollout te regelen..

[Rolfie]

Ik heb ook ellende gehad met mcafee of defender definities.

Had meer controle of gefaseerde iets gedaan, misschien.....

[Blokker_1999]

Je kan die quote ook anders interpreteren, namelijk dat critici nu aangeven dat zoiets al veel vroeger had moeten gebeuren, maar dat voorheen er niet echt mensen vreemd van opkeken.

De updates vallen namelijk onder de "Rapid Response Content", dat wil je sowieso niet door een wekenlang proces jagen lijkt mij. Bedrijven die daar een staggered rollout van wensen te doen moeten ook de nodige procedures hebben en de nodige mankracht om het goed te doen of alsnog vertrouwen op automatische getrapte verdeling.

[klakkie.57th]

Weken ???

Kan ook om bv 12u cycles gaan. Zet je eerst je test servers in en als die allemaal massaal omvallen heb je tijd om te reageren.

[Powerblast]

Tja het blijft een afweging. Of je rolt alles in één keer uit en je krijgt wat we hebben gehad. Of je doet stapsgewijs een update uitrol. Volgens mij kiest Windows ook voor het laatste, dus die hebben dan ook altijd een groep die iets later komt qua security fixes dan de rest denk ik.

Probleem hierbij zal vooral zijn dat je marge tussen de groepen wel redelijk moet zijn wil je critical issues zien. En dat wil je juist zo kort mogelijk houden bij security fixes.

[graey]

Het is bij deze dingen echt geen afweging waarbij er een ander nadeel is dan 'staggered is meer moeite'. Zeker als je binnen sector/branche staggered: één bank eruit of alle? Één vluchtmaatschappij of alle? Dit is een bedrijf met genoeg marktpenetratie en impact dat het sowieso zin heeft, zoals te merken was. En genoeg critici benoemden dit risico voor het zich voltrok. Pure laksheid om geld te besparen.

[jaapzb]

Een bedrijf als dit zou altijd een testomgeving moeten hebben waar hun software op draait, waar deze definities op ingeladen worden, en een QA-team die op deze acceptatieomgeving tests uitvoert (al dan niet geautomatiseerd). Als je zo veel installs hebt als hun, dan is het echt niet te verdedigen dat ze dit niet hebben.

Voordat je uberhaupt mag nadenken over rollout naar productiesystemen moet je echt eerst door zo'n acceptatietest heen.

Dat dit kon gebeuren zegt m.i. genoeg over de engineeringscultuur daar (wat vaak weer een product is van de managementcultuur).

[foppe-jan]

je denkt volgens mij iets te heikneuterig. Dit was een bedrijf dat bewust reclame maakte om miljardenbedrijven (en/of ziekenhuizen) als klant te krijgen. Dan moet je gewoon zorgen dat je dit van te voren op orde hebt, anders neem je je klanten niet serieus. Kan ook prima, maar daar waren ze te lui voor.

[tweakert4plus]

Denk eerder aan een doordrammende managerscultuur die worden afgerekend op 'scoren', zoals jaapzb (minofmeer) al aangaf.
Ook op https://clownstrike.lol/crowdmad/ werd een filmpje gepost waarin een manager de opdracht geeft aan de engineer de update te pushen, ondanks dat deze aangaf de tests nog niet geheel waren uitgevoerd.

'Iets' in het proces vernieuwen en dan niet het volledige pad aan afhankelijkheden meenemen in dit vernieuwingsproces geeft aan dat er tijdnood was. Ook de manager zal van bovenaf druk hebben ervaren en daardoor dan maar stappen over te slaan.
Al met al, geen (werk-)cultuur dat je één-twee-drie gaat veranderen en met die druk wordt het werken daar ook weer niet beter door.

[Mellow Jack]

Niet te snel vergeten dat een enkele test had geresulteerd in een blue screen of death. Dus ja, eerst intern testen en daarna gefaseerd releasen als je nieuwe features toevoegd.

Staat los van nieuwe definities toevoegen o.b.v. reeds geteste functionaliteit (waar jij op doelt)

[SunnieNL]

Als ze de uitrol eerst hadden gedaan op een aantal interne machines en daarna intern met daarna naar buiten, dan was deze fout toch gelijk ontdekt. Het is niet dat het bij sommige Windows machines wel en bij sommige niet gebeurde op het moment dat ze de nieuwe bestanden kregen. Ze hadden het allemaal.
Dat had toch gewoon direct opgemerkt moeten worden?
Dat intern uitrollen kan in 15 minuten wel getest zijn om de grote problemen eruit te halen.Bij de eerste machine hadden ze het probleem in 30 seconde kunnen spotten.

[Reactie gewijzigd door SunnieNL op 6 augustus 2024 22:19]

[raro007]

[...]
Zeker omdat een gefaseerde uitrol redelijk wat tijd kost, je moet eerst wachten of je geen feedback krijgt vanuit de eerste groep.

ik denk dat als de pc's niet meer werken zij best wel snel feedback zullen krijgen.

[the_stickie]

Dunno, als al 'mijn servers' in BSOD gaan door een automatische (onzichtbare/ongeweten) update is niet mijn eerste reflex vendors/partners te contacteren, wel een restore starten om alles weer 'up' te krijgen en pas nadien een RCA doen - die al dan niet de juiste rootcause bovenhaalt zodat de vendor/partner op de hoogte wordt gebracht. Ik gok dan enkele dagen verder te zijn...

[raro007]

maar een restore duurd een dat paar dagen precies dus je komt gouw achter waar het aan ligt?
daarbij niet vergeten als jij een restore doet en die antivirus weer gaat bijwerken dan breekt die jou pc weer.

[the_stickie]

daarbij niet vergeten als jij een restore doet en die antivirus weer gaat bijwerken dan breekt die jou pc weer.

jah, dat kan een deel van het proces zijn Of, zoals bij Crowdstrike: de bewuste update wordt al 'lang' niet meer verdeeld.

Gelukkig kan ik op een paar minuutjes een server restoren - al heb ik daarvoor wel wat dependencies die misschien ook nog eerst 'opgelost' moeten worden.
Maar ook met een paar minuutjes per server ben ik een dag of meerdere dagen bezig om alles te restoren en rudimentaire testing te doen (enkele honderden vm's - niet eens zo'n grote omgeving, wel vele TB's die heen en weer moeten).
In die tijd zou ik waarschijnlijk vooral collega's bij andere klanten en misschien Microsoft gecontacteerd hebben.

[TheVivaldi]

Ik vind het vooral opvallend, omdat toen ik het me bij een van de vorige artikelen afvroeg, ik allemaal nullen, -1'en en bakken aan kritiek kreeg. Maar als “professionele critici” het zeggen en CrowdStrike zelf ook, dan is het allemaal paix en vree.

[Netrunner]

vind die rapportjes wel sjiek, wanneer komen de aanklagen...

[The Fatal]

Zo iets relatiefs simpels, zon grote impact.
Dit laat nog maar eens zien dat automatisch updaten niet echt altijd goed is. Liever eerst handmatig op een test systeem controleren, daarna pas uitrollen.

[Blokker_1999]

Ja, en dan op zaterdag een nieuwe zero-day in het wild en kom je maandag toe en nog voor jij je resultaten kunt valideren blijkt heel je bedrijf geinfecteerd te zijn.

1 van de weinige stukjes software waar je graag heel snel de updates wenst te hebben is je beveiligingssoftware.

En wie zegt dat je testsystemen representatief zijn voor je productieomgeving of dat jij alle fouten daarmee gaat afvangen? Crowdstrike voert ook testen uit en toch is deze update uitgerold geraakt ondanks de desastreuze gevolgen ervan.

[the_stickie]

Ik heb ook graag asap alle laatste definities, maar als de agent/de engine/de code wordt aangepakt (er functionalitieten worden toegevoegd), hoop ik toch zelf wat conrole over de rollout te hebben.
Zowat elke niet-volledig-cloud endpoint protection tool biedt de mogelijkheid om de agent versies zelf in de hand te houden...

[108rogar]

Wat ik hierboven lees is dat deze code al eerder was aangepast, maar dat er nu pas definities zijn aangeleverd die de bug triggeren. Oftewel, alleen de nieuwe versie met codewijzigingen tegenhouden voorkomt dit probleem niet, je moet ook je nieuwe definities tegenhouden.

[The Zep Man]

Ja, en dan op zaterdag een nieuwe zero-day in het wild en kom je maandag toe en nog voor jij je resultaten kunt valideren blijkt heel je bedrijf geinfecteerd te zijn.

1 van de weinige stukjes software waar je graag heel snel de updates wenst te hebben is je beveiligingssoftware.

Van mijn beveiligingssoftware verwacht ik dat die ook goed getest is en dat die tiered wordt uitgerold. Bovendien hoeven niet al mijn systemen kwetsbaar te zijn voor elke 0-day door een gelaagde beveiliging.

En wie zegt dat je testsystemen representatief zijn voor je productieomgeving of dat jij alle fouten daarmee gaat afvangen?

Je testsystemen hoeven niet representatief te zijn. Daarvoor heb je acceptatiesystemen. Als die niet representatief zijn dan heb je die niet goed ingericht.

Crowdstrike voert ook testen uit en toch is deze update uitgerold geraakt ondanks de desastreuze gevolgen ervan.

Waardoor blijkt dat hun QA-proces niet voldoende is om dit soort fouten op te vangen.

Laten we niet bedrijven die brakke kernel drivers schrijven knuffelen.

[Reactie gewijzigd door The Zep Man op 6 augustus 2024 21:44]

[raro007]

wat bedrijven ook doen met windows met een goed reden erachter..

[J_van_Ekris]

Dit laat nog maar eens zien dat automatisch updaten niet echt altijd goed is. Liever eerst handmatig op een test systeem controleren, daarna pas uitrollen.

Volgens nij is dat het laatste wat je wilt doen met een virusscanner. Zeker als je een internet-facing systeem hebt kun je maar beter zorgen dat je bij bent met je updates, en zorgen dat je fallback-opties hebt (zoals werken met backups/containers die je weer up brengt als de update mislukt).

[Mellow Jack]

Groot verschil tussen nieuwe features en nieuwe virus definities

[Blokker_1999]

Het is uiteindelijk een definitie update die de nieuwe code aan het werk heeft gezet en alles heeft doen crashen.

[Mellow Jack]

Ja precies en dat ga je toch testen voordat je zoiets doet? Het is functionaliteit wat je voor het eerst in het wild gaat toepassen.

Het is niet alsof het geheel ineens onveilig is als dit een uurtje of wat later live komt. Anders zou hun hele software tot dit punt onveilig zijn

Het is letterlijk een kwestie van een systeem klaar zetten (een verse Windows deployment kost je + - 15 minuutjes), update pushen (5 minuutjes), rebooten en tadaaa BSOD. Voor een beetje systeembeheerder is dit max een half uurtje scripten waarna dit bij elke update uitgevoerd kan worden

[J_van_Ekris]

Het is letterlijk een kwestie van een systeem klaar zetten (een verse Windows deployment kost je + - 15 minuutjes), update pushen (5 minuutjes), rebooten en tadaaa BSOD. Voor een beetje systeembeheerder is dit max een half uurtje scripten waarna dit bij elke update uitgevoerd kan worden

Achteraf praten is altijd makkelijk. Nu weet je waar je naar moet zoeken. En beheerders hebben het niet druk of zo, die doen dit scripten er wel bij.

Sommige zaken kun je niet laten liggen totdat er eens iemand de tijd neemt om te testen. Het is gewoon voor een organisatie met beperkte middelen niet te doen om het bij te houden. Je moet er vanuit kunnen gaan dat er door een partij als Microsoft en CrowdStrike goed getest wordt. Als je iemand dit moet laten testen en hij krijgt er een stel hoog prio calls tussendoor ben je zo een dag (24 uur) verder. Als je in een vakantieperiode zit is twee weken zo voorbij. Daarom zijn we ooit met automatic updates begonnen.

[Mellow Jack]

Wat is in mijn voorbeeld niet geautomatiseerd? Je kan het natuurlijk handmatig doen maar t is super simpel om een aantal systemen klaar te hebben staan waar updates automatisch worden gepushed.

Het lijkt me tegenwoordig redelijk standaard dat een beetje bedrijf elke Windows updates automatisch installeert op zogenaamde template machines (ik ben gewend... 1 current versie, 1 met de toekomstige versie en 1 met latest greatest). De gebruikte build agents in de CICD pipelines worden wekelijks ververst. E software wordt direct getest. Voordat de dag überhaupt begint weet iedereen (systeembeheer en ontwikkelaars) waar ze aan toe zijn en waar eventuele problemen zijn. In de gehele stack kan je - 1 versie doen. Het kan bijv dat Windows updates iets kapot maken en dat mag geen invloed hebben op de ontwikkelaars.

Heb je zo'n omgeving niet dan heeft dat naar mijn mening maar een paar oorzaken. Het is of onkunde van het personeel of gemakzucht vanuit management... In dit geval voelt het voor mij als het 2e... Ze willen goedkoper zijn dan de concurrentie en ipv iets slimmer te doen dan de concurrentie hebben ze ervoor gekozen om bepaalde aspecten gewoon niet te doen (want unit testen en code validators zijn voldoende ofzo)

[De Vliegmieren]

Nee, dat is absoluut niet het laatste wat je wilt doen met een virusscanner.

Met jouw logica kan Microsoft ook alle QA voor patch Tuesday overslaan, want dat is toch het laatste wat je wilt met patches voor zero-day flaws.

Alle code die naar een groot aantal systemen wordt gepusht moet worden getest, en daarna gefaseerd worden uitgerold. En als beide ontbreken, dan krijg je situaties als die we laatst gezien hebben.

[J_van_Ekris]

Met jouw logica kan Microsoft ook alle QA voor patch Tuesday overslaan, want dat is toch het laatste wat je wilt met patches voor zero-day flaws.

Dat is niet wat ik gezegd heb. In andere posts zeg ik dat juist partijen als Microsoft en CrowdStrike hun verantwoordelijkheid moeten pakken en moeten zorgen voor een betrouwbaar product. Maar het introduceren van extra menselijke handelingen als fixes en AV-definities aan de klantkant is onverstandig, omdat malwaremakers ook die definities en updates zien en er vaak een exploit volgt.

[De Vliegmieren]

Al deze stappen kunnen geautomatiseerd verlopen. En zelfs als dat niet mogelijk zou zijn (wat dus niet zo is), dan zou het nog steeds beter zijn om dat dan maar deels handmatig te testen alvorens het naar miljoenen endpoints uit te rollen.

[Reactie gewijzigd door De Vliegmieren op 7 augustus 2024 09:50]

[jip_86]

Jeetje, out of bounds testing is toch ongeveer les een bij unit tests. Bizar dat er nooit getest is op zulke grenzen.

[trab_78]

Inderdaad! Ik zie veel reacties ingaan op het idee dat men nu "staggered" releases wil gaan doen en welke impact dat wel of niet kan hebben op het snel uitrollen van nieuwe "templates" of "definities". Waar dat allemaal aan voorbij gaat, is dat deze out of bounds bug maanden geleden al gevonden had moeten worden, toen men die nieuwe software releasede. Die release had uitvoerig getest moeten worden, waarbij juist ook op de grensgevallen gelet werd. De conclusie lijkt nu te worden dat die "templates" goed getest moeten worden, maar het gaat er juist om dat de software die die templates interpreteert beter getest moet worden.

[SunnieNL]

In het definitieve rapport staat dat die bug geen softwarefout was

Ik snap die opmerking dan ook niet. Dit is toch duidelijk een softwarefout geweest?

[TheVivaldi]

https://www.vandale.nl/gr.../nederlands/betekenis/bug

bug (de; m; meervoud: bugs) fout in een computerprogramma

Dus ja, een softwarefout.

[comatoast]

Als je het 'template' niet als software ziet, maar als configuratie voor een bepaalde controle (kan mss in een json of yaml) , en de 'software' als de applicatie die deze configuratie interpreteert, dan kan het een template-fout zijn en geen software-fout.

Wanneer in de docs van de software staat 'max 20 parameters' en er zitten er 21 in het template, dan kún je het een template-fout noemen als je echt je best doet, maar er zou daarentegen ook een unit-test moeten zijn die de handhaving van de limiet controleert en volgens het rapport werden nieuwe templates niet eens door een staging omgeving getrokken

[Rixard]

Het is wel een fout hoe de software omgaat met fouten in een template. Een nette foutmelding zou goed zijn, maar een blauw scherm is dat uiteraard niet.

[fenrirs]

Sterker nog, bij het uitbreiden van de velden had een developer ergens aan de bel moeten trekken.

Wat ik uit het verhaal begrijp is dat de validator met 17,18,19,20 definities overweg kon, maar met 21 niet. Klinkt als hard gecodeerde grens.

Mijn vermoeden:die grens zit er al lang in en de desbetreffende developer is niet meer in dienst

[OruBLMsFrl]

Zou ook nog een bedrijf cultureel aspect in kunnen zitten, dat ze te veel hebben gedrukt en gestuurd van bovenaf dat het niet mocht falen, dat er altijd in ieder geval iets van beveiliging ingeladen moest worden, klanten niet zonder mochten komen te zitten. Weet ik niet maar kan typisch zoiets zijn waar mensen dan toch huiverig worden en haast onbewust zulke checks en filters maar zwakker maken of weglaten, waardoor vanuit zulk beleid dan uiteindelijk dit soort bugs bovenkomen. Wil maar zeggen, dit persbericht zegt enkel wat er mis was, maar niet hoe zoiets tot dit gekomen is.

En dat het zo gekomen is, is vanuit het meesterschap kernel driver softwareontwikkeling erg vreemd wel, want juist in kernel space zou je met zulke dingen normaal flink extra bezig zijn om vooral de rest van de kernel en het systeem te beschermen tegen je eigen fouten, laat staan input sanitation. Nu stopt de hele PC, maar dit was natuurlijk ook maandenlang een potentieel security risico, out of bounds in kernel memory kun je vermoedelijk van alles mee natuurlijk als je als aanvaller weet wat je doet.

[kodak]

Hoe is dit bizar? Want we kunnen wel de verwachtingen hebben dat men op een professionele manier test en software uit brengt, maar wie doet aan controle van het bedrijf op het gebied van ontwikkelingen en testen? Ik zie niet dat klanten inzicht eisen. Er is geen specifieke wetgeving het voldoende te laten controleren. Er is geen wetgeving om er transparant over te zijn naar de klanten. Maar ondertussen willen grote bedrijven het wel vertrouwen alsof men dit soort gebreken niet kan verwachten.

[Stannieman]

In het definitieve rapport staat dat die bug geen softwarefout was

Het probleem ontstond omdat de code interpreter verwachtte dat er maximaal twintig velden in de template zouden staan.

Als je code niet om kan gaan met input die wel geldig is dan is dat spreekwoordelijk de definitie van een softwarefout.

[njitter]

Wie heeft hier lopen slapen bij het maken van de Change Control. Je breid het aantal parameters in je template uit van 20 naar 21 en dan test je dit niet even?

[paradoXical]

Onze admin draait alle updates op een test systeem en zodra dat goed is de rest van het serverpark aan de beurt. Klein bedrijf. Bij een grote klant van ons lag alles eruit (600 servers) behalve de aix/rhel servers. Dikke stress daar 🤭

[poktor]

"Handmatige testen". Dus toch menselijk falen.

[elmuerte]

Dus a) slechte input validatie, b) slechte automatische test, c) geen (automatische) smoke test.

Ze gaan a) en b) fixen, maar dat is natuurlijk niet structureel. Zonder c) zullen dit soort problemen voor kunnen komen. Met een smoke test waren ze heel snel er achter gekomen dat deze change een grote fout bevatte.

[HyperioN]

Als ik het rapport goed interpreteer, gaan ze wat jij noemt "smoke test" wel ook toepassen als mitigerende maatregel:

6. Template Instances should have staged deployment
Findings: Each Template Instance should be deployed in a staged rollout.
Mitigation: The Content Configuration System has been updated with additional
deployment layers and acceptance checks
Staged deployment mitigates impact if a new Template Instance causes failures such as
system crashes, false-positive detection volume spikes or performance issues. New
Template Instances that have passed canary testing are to be successively promoted to
wider deployment rings or rolled back if problems are detected. Each ring is designed to
identify and mitigate potential issues before wider deployment. Promoting a Template
Instance to the next successive ring is followed by additional bake-in time, where telemetry
is gathered to determine the overall impact of the Template Instance on the endpoint

[Blokker_1999]

Als je het document leest dan zie je dat ze wel degelijk een smoke test doen. De nieuwe template was reeds actief bij verschillende klanten zonder problemen, maar dat kwam dan weer doordat de 21ste parameter initieel gewoon als wildcard werd ingevuld. Het is pas toen men daar een specifieke waarde invulde dat het een probleem werd, en dan kom je opnieuw uit bij testing die foutief was opgezet.

[jmvdkolk]

Als ik het goed begrijp is het nog erger. De basics van secure programming worden niet uitgevoerd binnen een bedrijf dat in de kern van de security zit. Het probleem begint volgens mij voor a), nl. met mensen die de basics van programmeren qua security niet beheersen.

[cricque]

Dit is toch gewoon het probleem proberen te minimaliseren ... Ten eerste als je zoiets gaan upgraden dan test je toch dat het ook oude formaten ondersteund. Dat is toch altijd stap 1. Ze weten maar al te goed welke versies hun klanten hebben, dus dit was toch info die je op voorhand had. Hoe je het ook wilt omschrijven dit is gewoon toch een probleem