Pieter Edelman
4 January 2018

2018 was slechts een paar dagen oud toen zich een goede kandidaat voor het beveiligingsprobleem van het jaar meldde: Meltdown en Spectre. Zo’n beetje elke moderne processor blijkt vatbaar voor een reeks side channel attacks waarmee applicaties afgeschermd geheugen kunnen lezen. Verhelpen van de problemen vereist aanpassing van alle applicaties en inboeten aan performance.

De aanvallen zouden eigenlijk pas deze week onthuld worden, maar een blogger wist eerder al zijn vingers achter een van de problemen te krijgen aan de hand van een discussie op de ontwikkelaars-mailinglijst van de Linux-kernel. Intel was de gebeten hond; volgens de eerste berichten zouden besturingssystemen tientallen procenten moeten inboeten op prestaties om een probleem op Intel-processoren op te lossen. AMD of bij de alternatieve architectuur van Arm zouden hier niet gevoelig voor zijn.

Maar al snel bleek dat het probleem veel uitgebreider was. Ook sommige processoren Arm bleken kwetsbaar voor het ‘Intel-probleem’, en vereisen dezelfde prestatieverlagende oplossing. En het is niet gezegd dat andere fabrikanten niet kwetsbaar zijn, het is alleen tot nog toe niet gelukt om de exploit werkend te krijgen.

Maar daarnaast bleek het slechts het topje van de ijsberg. Er bleken vergelijkbare exploits te bestaan die ook voor AMD en Arm werken, en die zijn niet met een simpele os-wijziging op te lossen. Maar eigenlijk lopen zo’n beetje alle moderne cpu-architecturen gevaar – het is vooral een kwestie van interesse door beveiligingsonderzoekers. Volgens Red Hat weet het al van gerelateerde exploits voor serverarchitecturen op basis van IBM’s System Z- en Power-processoren.

 advertorial 

8-bit Microcontrollers Still Anchor the Majority of Embedded Designs Today

They are tiny, but vitally important. The market for 8-bit microcontrollers continues to grow strongly as a key part of the drive to digitalisation, highlighted by the current chip shortages. Read more about Microchip’s 8-bit devices.

Intel Pentium Silver and Celeron chip

Wat is er aan de hand?

De aanvallen draaien om het onbedoeld lekken van informatie bij speculative execution in de cpu. Moderne processoren persen zo veel mogelijk prestaties uit hun rekenhardware door te gokken welke instructies waarschijnlijk als eerste zullen volgen. Als later blijkt dat ze fout hebben gegokt, dan worden de resultaten gewoon weggegooid. Voor software blijft het verborgen wat er achter de schermen allemaal gebeurt.

Maar de speculatieve executie laat wel haar sporen achter in het systeem. Met het nodige kunst- en vliegwerk zijn sommige van die sporen te achterhalen. Een speculatieve processor zal bijvoorbeeld soms vast met de opgevraagde data aan de slag gaan voordat die check is afgerond om de boel niet te vertragen.

Dat is in principe niet erg, want de software krijgt de resultaten pas te zien als de controle positief uitvalt. Maar de waarden zijn op dat moment wel vanuit het werkgeheugen naar de processorcache gehaald. Door bijvoorbeeld te meten hoe lang het duurt om bepaalde waarden op te vragen, kan een hacker uitvissen of ze uit de cache komen of helemaal uit het werkgeheugen moeten worden opgehaald.

Dat is te misbruiken om geheime informatie buit te maken. Manipuleren van dergelijke gegevens is weliswaar niet mogelijk, maar dat is een schrale troost; de gegevens die een hacker kan opvissen, kunnen zomaar toegang geven tot andere manieren om op het systeem te komen.

De exploits komen natuurlijk niet uit de lucht vallen, maar bouwen voort op eerder werk; ze werden door verschillende onderzoekers gelijktijdig ontdekt. De onderzoekers hebben ook een fancy naampje bedacht: het ‘Intel-probleem’ staat bekend als Meltdown, de andere twee lekken heten samen Spectre. Google en de technische universiteit van Graz waren betrokken bij het ontdekken van beide lekken, en daarnaast deden verschillende specialisten uit het bedrijfsleven en de onderzoekswereld een duit in het zakje.

Meltdown onderscheidt zich van Spectre doordat het zich richt op hardwaregebaseerde afscheiding. Applicaties kunnen typisch alleen het geheugen lezen dat aan hen is toegewezen, maar als optimalisatie kennen veel besturingssystemen ook de geheugenruimte van de kernel toe aan de applicatie. De toepassingen doen namelijk regelmatig systeemaanroepen die de kernel moet afhandelen, en het schakelen tussen de twee – een context switch – kost relatief veel tijd. Door het kernelgeheugen als het ware onderdeel te maken van de applicatie, is dit niet nodig.

De optimalisatie kon worden ingebouwd doordat processorarchitecturen zoals X86 en Arm hiervoor ingebouwde beveiligingsmechanismen bieden. De kernel draait met de hoogste permissies, waardoor het geheugen niet leesbaar is voor software die met minder rechten draait, zoals drivers en applicaties. Maar Meltdown haalt die hardwaregebaseerde muren omver. Door de bijwerkingen van speculatieve executie uit te buiten, kan een applicatie toch bij het verboden kernelgeheugen komen.

Spectre gebruikt dezelfde methodes maar richt zich op softwarematige controles op geheugentoegang. Een besturingssysteem zal doorgaans een applicatie doen crashen als dat geheugen van een andere toepassing probeert te lezen. Goed geschreven software checkt daarom zelf eerst of het wel bij een bepaald geheugenadres mag. Spectre omzeilt deze checks doordat code die normaal nooit ‘echt’ draait wel speculatief kan worden uitgevoerd.

Wat nu?

De oplossing voor Meltdown is simpel: besturingssystemen moeten de kernel- en applicatiegeheugenruimte van elkaar scheiden. Linux, Windows en MacOS hebben die fixes doorgevoerd. Het nadeel van aanpassing is uiteraard dat er vaker context switches nodig zijn. De impact hiervan loopt sterk uiteen: op sommige benchmarks blijft die onder de procent, maar sommige toepassingen merken een verschil van tientallen procenten. Waarmee niet gezegd is dat dat kan worden verbeterd met de juiste maatregelen.

De fix is niet voor alle processoren nodig; sommige cpu’s missen de specifieke features om het probleem werkend te krijgen en daarvoor is de wijziging uitgeschakeld. Maar het is de vraag voor hoe lang, want althans voor Linux was de aanpassing bedoeld voor een ander, minder groot beveiligingsprobleem. Het blijkt namelijk dat address space layout randomization, een techniek die beschermt tegen het uitbuiten van kwaadwillende software, vaak toch wel te omzeilen is. Vanuit dat opzicht is het misschien sowieso een goed idee om kernel- en applicatiegeheugen strikt te scheiden.

Wat betreft Spectre ligt de situatie ingewikkelder. Bij deze aanval kan correct geschreven software zo gemanipuleerd worden dat het geheugen van andere applicaties lekt. Virtuele machines zijn een dankbaar slachtoffer, want die kunnen naar believen aangestuurd worden door een hacker.

Om die problemen te omzeilen, moet de software op laag niveau kunnen aangeven dat een deel van de code niet speculatief mag worden uitgevoerd. Niet alleen moeten besturingssystemen worden aangepast, ook applicaties zelf moeten eraan geloven. Op dit moment wordt er hard gewerkt aan compiler-opties, bibliotheken en andere tooling waarmee de programmeur zijn beveiliging kan dichten.

Het Spectre-probleem heeft ook een grote impact op clouddiensten waarbij vele klanten dezelfde hardware delen door het gebruik van virtuele machines. De scheiding daartussen blijkt nu minder strikt dan gedacht. Aanbieders van dit soort diensten hebben wel oplossingen doorgevoerd, maar deels moeten hun klanten daarvoor ook in actie komen.

Conclusie

Er valt over te twisten of Meltdown en Spectre echt als beveiligingsbugs te bestempelen zijn. Veel media concludeerden aanvankelijk dat Intel geprutst had, en dat Arm en AMD veel betrouwbaarder zijn. Na publicatie van de details is die conclusie niet meer houdbaar. Algemeen hadden cpu-architecten deze onbedoelde side channel over het hoofd gezien.

Maar Linux-opperbaas Linus Torvalds heeft wel een punt als hij openlijk moppert dat ‘een competente cpu-engineer ervoor zou zorgen dat speculatie nooit de beschermingsdomeinen overschrijdt’. De Risc-V Foundation kon dan ook trots melden dat zijn opensource processorarchitectuur niet kwetsbaar is omdat er beter over veiligheid is nagedacht.

De problemen kunnen dan ook alleen echt opgelost worden met nieuwe cpu’s. Het zal echter nog zeer lang duren voordat alle kwetsbare processoren uitgefaseerd zijn. Tot die tijd moeten software- en microcode-updates het ergste kwaad beteugelen.

Gelukkig is niet elk probleem van toepassing op elke situatie, en is het nog knap lastig om ze daadwerkelijk uit te buiten. Voorlopig zijn de cloudaanbieders het zwaarst getroffen; die moeten toepassingen van derden toestaan op hun systeem en leunen sterk op virtualisatieoplossingen. Kwaadwillende applicaties op desktop-pc’s en smartphones kunnen de technieken ook uitbuiten. Vooralsnog zijn geen aanvallen via het internet bekend.

Maar het is waarschijnlijk slechts een kwestie van tijd voordat er schadelijkere varianten van de kwetsbaarheden worden ontwikkeld, bijvoorbeeld aanvallen die de Javascript-engines van een webbrowser misbruiken. De ontdekking van de kwetsbaarheden lijkt dan ook grote gevolgen te gaan hebben voor zo’n beetje de hele techwereld. Eigenlijk voor alles dat aan internet hangt, van Arm-gebaseerde iot-systemen tot big iron, tegen het licht gehouden worden om te kijken of speculatieve executie een gevaar kan vormen. En systemen in het veld moeten worden geüpdatet en de software worden aangepast. Dat is geen geruststellende gedachte.