3min

Tags in dit artikel

, ,

Speculatief misbruik

Het probleem ligt bij een ander stuk van de technologie. In het geheugen van pc’s en servers is er een belangrijk onderscheid tussen de user space en de kernel space. De user space bevat data die niet overdreven gevoelig is, terwijl in de normaliter erg goed beschermde kernel space de meest kritieke gegevens worden behandeld. Een normale instructie zonder toegang tot de kernel space zal nooit door de processor raken met toegang tot de data daar. Vraagt een normale user space-instructie toegang tot data in de kernel space, dan zet de processor de instructie stop. Niet zo als het om een speculatieve instructie gaat. De check gebeurt nog steeds, maar pas helemaal op het einde, wanneer blijkt dat de instructie daadwerkelijk moet worden uitgevoerd. De redenering hierachter kan je begrijpen: als de processor fout speculeert, worden alle wijzigingen teruggedraaid, en als de speculatieve instructie terecht wordt uitgevoerd, doorgaat ze een finale privilegecheck voordat de uitvoering wordt afgerond.

Lekke pipeline

Het probleem zit in de pipeline. Stel je eenvoudig voor dat een fictieve processor een pipeline van vier stappen heeft. In de eerste stap wordt data van het RAM-geheugen naar de processorcache geschreven, in de volgende stappen gebeuren er bewerkingen, en in de allerlaatste stap kijkt de cpu in het geval van de speculatieve instructie of ze wel moest worden uitgevoerd, en of ze de nodige privileges heeft. Zelfs wanneer het antwoord op één van die vragen nee is, heeft een malafide speculatieve instructie wel wijzigingen kunnen aanbrengen in de processorcache. In die cache is data minder goed beschermd als in de kernel space. Het eerste Spectre-lek maakt van die tekortkoming in Intel-cpu’s gebruik om gevoelige data uit te lezen. Een speculatieve malware-instructie haalt data zoals een wachtwoord uit de kernel space naar de cache, waarna ze terecht wordt stopgezet, maar de cache intussen wel is aangepast. Aan de hand van die aanpassing kan malware vervolgens aan je wachtwoord raken.

Lees ook: Gevaarlijke nieuwe Spectre-varianten bezorgen Intel opnieuw hoofdpijn

Eén trucje, veel variaties

De nieuw ontdekte variaties op Spectre gaan nog een stapje verder. Zij vragen niet om beveiligde data te lezen, maar proberen malafide code weg te schrijven op geheugenlocaties waar ze geen toegang tot hebben. Een buffer overflow ligt hier aan de basis, en opnieuw is Intels laattijdig geïmplementeerde privilegecheck op speculatieve executies verantwoordelijk. Waar de eerste variant op Spectre gevoelige data probeert te lezen door stiekem gegevens uit de kernel space naar de cache te schrijven, proberen Spectre 1.1 en Spectre 1.2 data te schrijven naar een geheugenadres dat niet bestaat. Laten we zeggen dat een speculatieve instructie toegang heeft tot een bereik van vijf verschillende opeenvolgende adressen in het geheugen. Tijdens de speculatieve uitvoering vraagt de instructie om een blokje malwarecode weg te schrijven naar adres zes. Normaliter stopt de processor de code, omdat adres zes in de context van de instructie niet bestaat. In speculatieve modus gebeurt die check niet, en wordt de code in de praktijk weggeschreven naar een geheugenadres dat tot een andere set instructies behoort. Opnieuw zal de instructie door de cpu worden gestopt zodra ze van speculatief naar reëel verandert, maar opnieuw is het cachegeheugen in deze fase reeds aangetast. Een goede aanval zorgt er zo voor dat een proces met de juiste rechten data vanuit de cache inlaadt die voordien is overschreven, waardoor het goedaardige proces plots kwaadaardige dingen begint doen.

Table of contents