Er zijn vier jaar verstreken sinds de eerste publicatie van het onderzoek naar Spectre en Meltdown, hardware-kwetsbaarheden in moderne processors. Sindsdien hebben onderzoekers verschillende soortgelijke kwetsbaarheden ontdekt, die mogelijk vertrouwelijke gegevens kunnen lekken. De onderzoekers lieten ook voorbeelden zien van aanvallen waarbij gebruik werd gemaakt van deze kwetsbaarheden, hoewel het onwaarschijnlijk is dat de meeste daarvan in het echt zullen worden gebruikt. In deze post kijken we naar de huidige stand van zaken met betrekking tot deze hardware-problemen en naar het potentiële gebruik ervan om bedrijven aan te vallen.

Verschillende varianten van Spectre

De oorspronkelijke aankondiging van augustus 2018 onthulde drie kwetsbaarheden: Spectre v1 en v2, en Meltdown. Deze kwetsbaarheden hebben verscheidene gemeenschappelijke kenmerken:

De exploitatie ervan behelst meestal de uitvoering van schadelijke code op een kwetsbaar systeem, zij het met lage privileges. De gevaarlijkste optie is een aanval via een browser bij het bezoeken van een “geïnfecteerde” webpagina.
Praktische exploitatie vereist een aantal voorwaarden. Zo moet bijvoorbeeld de code van de aangevallen applicatie het lekken van gegevens mogelijk maken, en een zogenaamde “gadget” hebben, waartoe de toegang de aanval mogelijk maakt.
Het gegevenslek zelf gebeurt via nevenkanalen. Hierdoor is de snelheid van het gegevenslek uiterst laag.
Bij een geslaagde aanval zijn er misschien zelfs helemaal geen sporen van ongeautoriseerde toegang tot gegevens.

Juist dit laatste argument wekte de bijzondere belangstelling voor dit schijnbaar theoretisch wetenschappelijk werk. In alle gevallen maakten de onderzoekers gebruik van het branch prediction-systeem. Dit mechanisme, dat meer dan 20 jaar geleden werd geïntroduceerd, maakt het mogelijk de prestaties te verhogen door een reeks instructies uit te voeren nog vóór een expliciet verzoek van het programma om deze uit te voeren. Als zo’n voorspelling juist is, zullen de processormiddelen efficiënter worden gebruikt. Als de voorspelling daarentegen fout is, worden de berekeningen gewoon weggegooid.

Proof of concept voor Spectre v1 toonde aan dat de processor gegevens leest die ontoegankelijk zouden moeten zijn voor het programma. Deze gegevens wordt opgeslagen in de cache en kan daar via zijkanalen worden opgehaald. Dit mechanisme werd veilig geacht, omdat het foutief gelezen “geheim” niet aan het programma werd doorgegeven. Maar onderzoekers hebben manieren gevonden om die gegevens indirect te lezen.

Na de publicatie van het werk over Spectre en Meltdown werden er nog meer soortgelijke kwetsbaarheden ontdekt. Onderzoekers blijven naar nieuwe methoden zoeken om geheime gegevens te ontfutselen door de kwetsbaarheden van processors uit te buiten. De samenvattende tabel van Intel vermeldt meer dan 20 van dit soort problemen, naast de oorspronkelijke drie.

Hoe u Spectre kunt bestrijden

In theorie zijn er drie manieren om een kwetsbaarheid van een processor minder kwetsbaar te maken: leveranciers kunnen een microcode-update uitbrengen voor bestaande processors, ze kunnen nieuwe CPU’s aanpassen, of proberen het probleem op te lossen via de software-updates. Vaak is voor echte mitigatie een combinatie van firmware- en software-updates nodig. De nieuwe microcode die een deel van de kwetsbaarheden dekt, is al sinds de Haswell-generatie van 2013 beschikbaar voor Intel-processors. Hardware-oplossingen werden voor het eerst toegepast in de achtste generatie Intel-processoren, evenals in AMD’s Zen 2 CPU’s.

Software-oplossingen kunnen heel lastig zijn: als voorbeeld kunt u eens kijken naar de mogelijke wijzigingen in de Linux-kernel tegen Spectre v1 en v2. Er werd een breed scala van maatregelen besproken, afhankelijk van de doelstellingen van een bepaald systeem, waaronder het volledig uitschakelen van speculatieve code-uitvoering met ernstige gevolgen voor de CPU-prestaties.

Voor de meeste organisaties waarvan het bedrijfsmodel afhankelijk is van de prestaties van een groot aantal servers, zal een dergelijke prestatiedaling het meest merkbare effect zijn van anti-Spectre-maatregelen. Een relatief recente benchmark op de Phoronix-website, die de prestaties van diverse servertoepassingen onderzoekt, laat een prestatiedaling van gemiddeld 25% zien wanneer alle anti-Spectre-maatregelen in Linux OS zijn ingeschakeld.

Praktische aanvallen en proofs of concept

Ondanks het grote aantal aanvalstypen is de dreiging van gegevensdiefstal met Spectre nog steeds theoretisch. Hoewel elk onderzoek wat code bevat die het lek aantoont, betekent dit niet dat deze code tegen een echt systeem kan worden gebruikt. De typische beperkingen van deze demo’s of “proof of concept” zijn de volgende:

Ze demonstreren een willekeurig datalek. Het heeft misschien geen praktische waarde, het is gewoon willekeurige informatie waar de aanvaller nog niet eerder toegang toe had.
Onderzoekers creëerden ideale omstandigheden voor de aanval. Ze hadden bijvoorbeeld onbeperkte toegang tot het systeem. In dit geval is het niet nodig om complexe methoden voor het exfiltreren van gegevens te gebruiken.
Het demonstreert een echt datalek, maar dan wel onder zeer onwaarschijnlijke omstandigheden.

Het meest indrukwekkende theoretische werk (wat betreft de mogelijke gevolgen) is de NetSpectre-aanval. De onderzoekers slaagden erin uitbuiting op afstand aan te tonen met gegevensverwijdering met een snelheid van 15 tot 60 bits per uur. De beperkingen van de aanval zijn duidelijk: lage datatransmissiesnelheid, geëxfiltreerde gegevens bevatten een enorme hoeveelheid junkverkeer, plus kwetsbare code op de aangevallen server “op de juiste plaats” voor succes.

Vorig jaar werden er twee praktijkaanvallen getoond, die de ITW-omstandigheden zo dicht mogelijk benaderden. In maart toonde Google een leaky.page-concept: een webpagina die gegevens uit het RAM kan extraheren. In september werd er een Spook.js-aanval gedemonstreerd op de nieuwste (op het moment van het onderzoek) versie van Google Chrome (92) met Spectre-beveiliging (isolatie van webpagina’s in afzonderlijke browserprocessen). Deze methode maakte echte gegevensdiefstal mogelijk: onderzoekers kregen toegang tot de inloggegevens voor een sociaal netwerk, gegevens van een wachtwoordbeheerder en een afbeelding die door een gebruiker naar een privé-cloud was geüpload. Maar in al die gevallen was voor een succesvol datalek een “geïnfecteerde” pagina nodig die zich op hetzelfde domein bevond. Voor het stelen van een Tumblr-wachtwoord moet bijvoorbeeld schadelijke Javascript-code worden geüpload naar een andere pagina op hetzelfde sociale netwerk.

Dus hoe gevaarlijk is deze dreiging nou echt?

De Spook.js-kwetsbaarheid werd geneutraliseerd met een softwarepatch voor de Google Chrome-browser. Daarom is er op dit moment geen onmiddellijk gevaar dat de Spectre-kwetsbaarheden in reële omstandigheden worden uitgebuit. Alle bekende aanvallen zijn uiterst complex en vereisen extreem veel kennis en vaardigheid van aanvallers.

De meeste realistische proofs of concept zijn gepatcht, en zelfs zonder patches vereist de exploitatie ervan een groot aantal voorwaarden. Hoewel mediaberichten over echte “Spectre-exploits” niet zijn bevestigd, hebben beveiligingsleveranciers tools toegevoegd om bekende aanvallen te detecteren voor het geval dat, dus hoogstwaarschijnlijk kunnen bestaande malware-detectiemechanismen helpen om uw bedrijf te beschermen.

Toch mogen we de Spectre niet volledig negeren: het is belangrijk dat het onderzoek wordt voortgezet. Er is een kleine kans dat na verloop van tijd het “worst-case scenario” wordt ontdekt: een aanval waarvoor geen malware hoeft te worden geïnstalleerd en die gegevens laat lekken zonder sporen achter te laten.

Theoretisch is het mogelijk een gerichte aanval uit te voeren door gebruik te maken van kwetsbaarheden in de hardware, indien de waarde van de gestolen gegevens dit rechtvaardigt. Bescherming tegen dergelijke risico’s vereist serieuze investeringen in het identificeren van potentiële aanvalsvectoren, het opvolgen van de aanbevelingen van OS-ontwikkelaars, of het implementeren van bescherming, zelfs als dit ten koste gaat van een ernstige prestatiedaling. Maar voor de meeste bedrijven (ook grote bedrijven), is het voldoende om te vertrouwen op de ontwikkelaars van software en besturingssystemen, de fabrikanten van processors, en beveiligingsoplossingen.