In oude processors waren de instructie-sets hardwired in het ontwerp van de chip en deze konden later niet meer worden gewijzigd. Als er na de verkoop een fout werd ontdekt, was de enige manier om deze te verhelpen het terugroepen en vervangen van de hele CPU, wat zeer kostbaar is.

Bij moderne processors wordt niet meer met hardwired instructie-sets gewerkt. Inmiddels wordt gebruik gemaakt van update-bare code, waardoor het een stuk eenvoudiger is om nieuwe CPU's te ontwerpen: circuits hoefden niet opnieuw te worden getekend, wat de kosten verlaagde, tijd bespaarde en een prestatieverhoging bood. Bovendien maakte dit de processors update-baar, wat vooral in het geval van een bug aantrekkelijk is.

Helaas betekent deze open structuur ook dat men met een software-trucje toegang kan krijgen tot het interne geheugen van de CPU, waar kritieke informatie wordt opgeslagen. Dat is het probleem van Meltdown en Spectre. Met een dergelijk scenario werd nooit rekening gehouden. Het vereist namelijk deskundige kennis van de interne werking van de processor. Zo’n aanval leek alleen theoretisch en academisch. Maar het probleem is: alle moderne bedreigingsscenario’s beginnen als theoretisch of academisch - totdat iemand ze daadwerkelijk in de praktijk brengt.

Hoe nu verder?

De chip-makers moeten updates ontwikkelen die de beveiligingslekken afdichten. Deze moeten er snel zijn, maar ze moeten wel goed zijn. Een haastig ontwikkelde patch die andere dingen breekt is het laatste wat zowel klanten als fabrikanten willen. Intel heeft onlangs aangekondigd dat het één van de “Spectre” patches intrekt, omdat deze in sommige systemen willekeurige re-boots veroorzaakt. Microsoft heeft zelfs een “out of brand” patch ontwikkeld om de slechte Intel-patch uit te schakelen. Nieuwe (goede) patches zullen vermoedelijk nog even op zich laten wachten.

De slechte patches die in deze affaire zijn uitgebracht, hebben het toch al slechte imago van patches geen goed gedaan. Wanneer we in de media horen over bedrijven die door cyber-criminelen zijn aangevallen, omdat ze een bepaalde patch van twee jaar oud nog niet hadden geïnstalleerd, fronsen wij security-experts graag onze wenkbrauwen. En hoewel er nauwelijks een geldig excuus te bedenken is voor het twee jaar op de plank laten liggen van een kritieke update, is een licht gevoel van scepsis ten opzichte van patches wel te begrijpen. Toch hebben we geen keuze: als we lekken willen dichten, moeten we patchen. Maar hoe kan dat veilig?

Voor bedrijven is het van essentieel belang om een duurzame patch management-strategie te ontwikkelen. Onderdeel van de strategie kan zijn om een proefopstelling te maken van een aantal apparaten met de software die in het bedrijf gebruikt wordt, om zo patches te kunnen testen. Er zijn ook programma’s die patches aanbieden die extra gecontroleerd zijn. De kans dat je dan een patch installeert die met andere software conflicteert is dan veel kleiner. Bovendien voorkom je hiermee ook dat je nu een (reeds waargenomen!) als Meltdown/Spectre-vermomd stuk malware installeert.

(Bovenstaande bijdrage kwam tot stand in samenwerking met G DATA Software Belgium B.V.B.A. (Groot-Bijgaarden)).

Meer info: 070/350.129 of www.gdata.be.