Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door Sander van Voorst

Nieuwsredacteur

Meltdown en Spectre - Q&A

Gegevens uitlezen door cpu-lekken

04-01-2018 • 17:10

167 Linkedin Google+

De belangrijkste vragen

Schreven we eind vorig jaar nog over het nut van branded vulnerabilities, beginnen we dit jaar meteen goed met twee nieuwe varianten met een eigen logo en website. Onderzoekers hebben details over de zogenaamde Meltdown- en Spectre-kwetsbaarheden gepubliceerd, die zich in het geval van het tweede lek voordoen bij moderne processors van Intel, ARM en AMD. De kwetsbaarheden maken het mogelijk om geheugen uit te lezen van de kernel en van andere processen, iets dat eigenlijk niet zou moeten kunnen door geheugenisolatie. Omdat dit wel blijkt te kunnen, behoort toegang tot gevoelige gegevens zoals wachtwoorden en privésleutels tot de mogelijkheden. In dit artikel gaan we kort in op de belangrijkste vragen rond de gepubliceerde lekken. Tweakers sprak daarnaast met Herbert Bos, die hoogleraar Systems and Network Security aan de VU Amsterdam is en aan het hoofd staat van de VUSec-onderzoeksgroep.

Waar hebben de kwetsbaarheden mee te maken?

Volgens Bos hebben alle kwetsbaarheden te maken met een techniek die bekendstaat als out-of-order execution: het berekenen van een resultaat voor het eigenlijk nodig is. Een goed voorbeeld hiervan is 
speculative execution, een truc die tot prestatiewinst moet leiden bij het uitvoeren van programma's. Bos legt speculative execution uit met behulp van een voorbeeld. Stel dat een programma de volgende instructies bevat: "Als een waarde in het geheugen, die geheim is en niet zichtbaar behalve voor de kernel, gelijk is aan een waarde n, laad dan uit het geheugen de waarde van het n-de element uit een tabel." Vervolgens legt hij uit hoe de processor hier speculatief aan gaat rekenen en hoe dit tot het lekken van informatie kan leiden.

"Wat een moderne cpu doet om dit sneller te maken, is alvast de waarde uit het n-de element van de tabel te laden, terwijl hij nog aan het bepalen is of de eerste waarde in het geheugen eigenlijk wel gelijk was aan n.  Als dat inderdaad zo was, dan heeft hij meteen de juiste waarde te pakken en dat scheelt tijd. Als dat niet zo was, dan heeft hij die waarde voor niks geladen. Maar dat geeft niet, want de cpu gooit die waarde dan gewoon weer weg. We noemen het laden van die waarde een 'speculatieve' operatie.  Er is niks aan de hand, tenzij een aanvaller op een of andere manier kan zien welke waarde speculatief werd geladen."

Dat laatste blijkt nu juist het probleem te zijn, vervolgt Bos. "Een slimme (Meltdown-)aanvaller kan zien welk element in de tabel werd geactiveerd. Dit heeft te maken met de manier waarop moderne processoren data die ze net gebruikt hebben tijdelijk in de cache zetten, zodat ze daar in de toekomst heel snel toegang toe hebben. Helaas is juist die extra snelheid een 'side channel' om informatie te lekken voor aanvallers. Door zelf te kijken of element n in de cache zit, bijvoorbeeld door te kijken of toegang tot deze data sneller gaat dan gebruikelijk, weten zij of het programma de waarde n had berekend. Op die manier lekt dus informatie uit het meest beveiligde deel van de kernel."

Wat zijn de verschillen tussen Meltdown en Spectre?

Zoals in het voorgaande nieuwsbericht al is beschreven, laat Meltdown het uitlezen van kernelgeheugen toe, terwijl Spectre dat toelaat voor processen onderling. De onderlinge verschillen worden ook nog eens duidelijk gemaakt door een afbeelding die het werk is van beveiligingsexpert Daniel Miessler. Het patchen van Meltdown is volgens de ontdekkers mogelijk, terwijl het voor Spectre moeilijker is om een omvattende oplossing te bieden en systemen te beveiligen. De onderzoekers stellen dat een oplossing in veel gevallen gezocht moet worden in aanpassingen van processorontwerpen en updates voor isa's. In het Meltdown-paper schrijven de onderzoekers dat ondanks tegenmaatregelen een attack surface overblijft. Zo blijft het mogelijk om pointers te lekken, die gebruikt kunnen worden om de kaslr-beschermingsmaatregel voor kernelgeheugen te omzeilen. De zogenaamde Kaiser-patches zouden echter de beste tegenmaatregel zijn.

Afbeelding via Daniel Miessler

Wie is getroffen? 

Uit het gepubliceerde onderzoek blijkt dat Meltdown zich hoofdzakelijk beperkt tot Intel-cpu's. Een proof-of-concept van Project Zero werkte op een Xeon-cpu van de Haswell-generatie en ook in het Meltdown-paper schrijven de onderzoekers dat ze hun aanval niet werkend konden krijgen op ARM- of AMD-processors. Ze stellen wel dat er een kans bestaat dat een geoptimaliseerde versie van hun techniek alsnog succes kan hebben op deze architecturen. Veel Intel-processors zijn kwetsbaar, volgens onderzoekers gaan getroffen cpu's terug tot 1995.

Spectre werkt zowel op Intel-processors als op die van AMD en ARM. Er zijn verschillende varianten van Spectre, gekenmerkt door CVE-2017-5753 en CVE-2017-5715. Respectievelijk duidt Project Zero deze aan als bounds check bypass en branch target injection. De eerste variant testten de onderzoekers met succes op cpu's van alle drie de fabrikanten. Maar die variant werkt alleen op een AMD Pro-cpu als eBPF om de een of andere reden is ingeschakeld. Dit staat standaard uit. AMD heeft in een eigen bericht geschreven niet of nauwelijks vatbaar te zijn voor de CVE's eindigend op 5754 en 5715, die toebehoren aan Meltdown en een van de Spectre-kwetsbaarheden. Over CVE-2017-5753 zegt AMD alleen dat dit verholpen kan worden met patches.

Inschatting door AMD zelf, waarbij met variant 3 Meltdown wordt bedoeld

Ook ARM heeft een overzicht gepubliceerd. Daaruit is op te maken dat alleen de Cortex-A75 vatbaar is voor Meltdown en Spectre, andere in het overzicht genoemde processors zijn alleen kwetsbaar voor de laatstgenoemde aanval. Er staan nog wel drie exemplaren tussen, de A15, A57 en A72, die vatbaar zijn voor alleen een Meltdown-variant. Die behoeft volgens ARM echter geen patch.

Diensten als AWS hebben inmiddels maatregelen genomen. Hetzelfde geldt voor Google, dat een overzicht heeft gepubliceerd van getroffen diensten. Daarin is ook Android opgenomen, waarvoor deze maand patches zijn uitgekomen. Mozilla heeft eveneens een advisory gepubliceerd, waarin het schrijft dat uit interne experimenten blijkt dat een aanval via webcontent mogelijk is. Daarom heeft het eerste maatregelen genomen in Firefox 57. Chrome ontvangt tegenmaatregelen in versie 64, die op 23 januari moet uitkomen. In de tussentijd kunnen gebruikers site isolation inschakelen.

Wat is het risico? 

Het risico van Spectre voor gewone gebruikers is volgens Bos moeilijk in te schatten, omdat de aanval moeilijk uit te voeren is. Meltdown is makkelijker te gebruiken, maar daarvan bestaat er weer geen implementatie in Javascript. Het lijkt hem echter 'triviaal' om een dergelijke implementatie te ontwikkelen. Hij vervolgt: "Het probleem is sowieso dat dit soort kwetsbaarheden alleen maar erger worden. Meer en meer mensen gaan ernaar kijken en ontdekken dan nieuwe manieren om ze te misbruiken. Ondanks dat we deze kwetsbaarheden nog niet door criminelen misbruikt hebben zien worden, denk ik dat het een ernstig risico is."

Ook op de lange termijn kunnen de kwetsbaarheden effect hebben. "Dit soort aanvallen lijken de nieuwe frontlinie van computerbeveiliging. Waren zulke aanvallen tot voor kort nog te scharen onder science fiction, zien we nu elke paar maanden een nieuwe aanval in deze categorie. Het gevolg is dat besturingssystemen nu beduidend anders worden van structuur, dat veel van de aannames die we deden over de veiligheid van hardware opnieuw onderzocht worden en dat, specifiek voor deze kwetsbaarheden, computers significant langzamer worden."

Bos omschrijft de kwetsbaarheden als ernstig en stelt: "Zeker op computers waar code draait van meerdere gebruikers kan gevoelige informatie worden gelekt. Dit geldt bijvoorbeeld voor cloudomgevingen waar programma's van verschillende organisaties dezelfde fysieke hardware gebruiken, maar ook voor zoiets alledaags als een webbrowser, waarin voortdurend Javascript-code van websites wordt uitgevoerd."

Zijn er patches voor besturingssystemen?

Vooropstaat dat Meltdown patchbaar lijkt te zijn, terwijl dit voor Spectre moeilijker is. Verschillende fabrikanten hebben inmiddels patches gepubliceerd. Zo heeft Microsoft deze inmiddels beschikbaar gesteld voor Windows 10. Daarbij speelt de aanwezige antivirussoftware een rol, omdat sommige versies van av-suites niet compatibel zijn met de patches en het systeem deze daarom niet ontvangt. Beveiligingsexpert Kevin Beaumont werkt aan een overzicht waarin hij bijhoudt welke informatie door beveiligingsbedrijven naar buiten is gebracht. In de Linux-kernel zijn de patches in versie 4.15 vrijgekomen met backports naar versie 4.14.10. Ontwikkelaars voor de Linux-kernel werkten al een tijd aan zogenoemde Kaiser-patches. Die zijn begin december omgedoopt tot x86/kpti-patches, waarbij kpti staat voor kernel page table isolation. Volgens The Register is macOS gepatcht vanaf versie 10.13.2.

Draait mijn systeem trager door de patches? 

Onder meer Phoronix, Hardware Unboxed en Computerbase publiceerden benchmarks na het toepassen van de nodige patches. De tests van Phoronix betroffen Linux en wezen op aanzienlijke prestatievermindering bij toepassingen als FS-Mark-, Compile Bench- en PostgreSQL. Hardware Unboxed ondervond bij i/o-benchmarks op Windows nagenoeg alleen een noemenswaardige prestatievermindering bij 4k reads en acces time reads. Bij gaming zou er bij zowel Windows als Linux geen verschil in prestaties optreden. Vooral het uitvoeren van syscalls zou trager verlopen. Volgens Microsoft gaat 'de meerderheid' van de Azure-klanten geen prestatieverschil merken. Een kleine groep klanten zou lagere netwerkprestaties kunnen ervaren, maar dit zou op te lossen zijn door Azure Accelerated Networking te activeren.

Bos stelt dat er percentages tot 30 procent prestatievermindering worden genoemd, maar dat hijzelf niet gelooft dat het zo hoog zal uitvallen. "Ik geloof zelf niet dat het 30 procent zal zijn, maar zelfs 5 procent vertraging van vrijwel alle computers ter wereld levert een grote schade op. Daarnaast worden er wel veel patches voorgesteld, maar lossen de huidige patches het echte probleem niet op. Ze houden dan enkele varianten van de aanval tegen, maar het probleem blijft. Vooral de Spectre kwetsbaarheid blijft problematisch", aldus Bos.

Wie ontdekten de kwetsbaarheden? 

Bij de ontdekking van zowel Spectre als Meltdown was Jann Horn van Googles Project Zero betrokken. In de blogpost van het project is genoemd dat Intel, AMD en ARM op 1 juni van vorig jaar op de hoogte zijn gesteld. Voor Meltdown geldt dat deze kwetsbaarheid daarnaast door Werner Haas en Thomas Prescher van Cyberus is ontdekt, naast een team van de Technische Universiteit van Graz. Spectre werd naast Horn door Paul Kocher in samenwerking met verschillende onderzoekers ontdekt.

Reacties (167)

Wijzig sortering
Nu ik Meltdown en Spectre nog wat meer in detail heb bestudeerd wil ik ook nog eens proberen in detail uit te leggen wat er nu precies aan de hand is. Grappig genoeg werd net dit stuk geplaatst terwijl ik dit aan het schrijven was.

Beide exploits maken gebruik van het observeren van speculatieve executie. Dat is een eigenschap van out-of-order processor micro-architecturen, alhoewel ik niet zou uitsluiten dat bepaalde (vooral superscalar) in-order processors ook dergelijk gedrag gemeten zou kunnen worden. Speculatieve executie gebeurt als de processor denkt bepaalde instructies uit te moeten voeren, maar dit afhangt van een eerdere instructie waarvan het resultaat nog niet bekend is. Wanneer de uitkomst van deze instructie bekend is worden de resultaten van de speculatieve instructies weggegooid. Op architectureel niveau is het gedrag dus als gewenst, maar het is mogelijk om bepaalde side-effects te meten in de cache hierarchie en door precies geconstrueerde stukken code op deze manier informatie te lekken als side-channel.

De Meltdown attack is gebaseerd op een stuk code binnen de controle van de aanvaller, wat met speculatieve instructies alle data van de kernel kan blootleggen - en ook vaak van alle andere processen, als de kernel een complete physical address space mapping bevat. Het idee hoe zo'n aanval werkt had ik gisteravond geschetst, toevallig net voordat de details van Meltdown beschikbaar kwamen: Squee in 'nieuws: Intel ontkent berichten dat alleen zijn processors vatbaar ...

Het belangrijkste om te realiseren over Meltdown (Variant 3) is dat het doorgeven van speculatieve waarden van hogere privilege levels wel echt een bug is, die specifiek in Intel's moderne micro-architecturen voor lijkt te komen. Ik zou overigens niet uitsluiten dat er andere micro-architecturen zijn die een dergelijke bug bevatten. De reden dat dit gebeurt heeft te maken met verregaande optimalisaties voor het laden van data uit de L1 Data cache. De cache wordt benaderd tegelijk met de D-TLB, en blijkbaar wordt er niet op tijd bepaald of er permissie problemen mee waren, voordat de data via het bypass netwerk naar de volgende (speculatieve) instructies wordt doorgestuurd. Deze, zogeheten load-to-use latency, is iets waar je je micro-architectuur sterk voor wilt optimaliseren voor performance. Waarschijnlijk wordt er pas daarna een exceptie flag op deze instructie gezet, zodat de processor een exceptie neemt wanneer deze instructie retired/commit, op architectureel niveau correct, maar de informatie is dan al via een side-channel gelekt.

Spectre is een grotere klasse van problemen, die op een nog geavanceerdere manier informatie weet los te peuteren uit andere processen. Dit doen ze door de gedeelde branch predictor (BP) en branch target buffer (BTB) aan te vallen, wat heel erg standaard componenten zijn in zowat alle moderne processoren. Deze componenten zijn gedeeld, als in, gedeeld door verschillende processen afwisselend draaiende op dezelfde CPU core. Het is mij op dit moment niet duidelijk of het ook tussen twee HyperThreads zou werken; dat hangt af van of de micro-architectuur in kwestie de BP en BTB splitst of deelt tussen de threads.

Beide Spectre aanvallen werken op het zelfde principe. Door specifiek geconstrueerde instructie sequences te maken wordt of de BP of de BTB in een bepaalde staat gebracht. Als daarna een ander proces (of de kernel) op de core gaat draaien wordt hierdoor de speculatieve executie beinvloed. Deze kan dan weer meetbare side-effects opleveren, en op die manier data prijs geven.

De aanval via de BP is "Variant 1: bound check bypass". Door de BP te trainen met branches die binnen jouw virtual memory qua adres overeen komen met die binnen het virtual memory van de code die wordt aangevallen kan je proberen te forceren dat de volgende keer dat die code wordt uitgevoerd deze branch verkeerd voorspeld wordt. Het speculatieve pad achter deze verkeerd voorspelde branch zou dan een geheugen access moeten doen waarbij het adres afhankelijk is van de data, en je via cache preparatie en timing metingen (delen) kan achterhalen van de originele data.

De aanval via de BTB is "Variant 2: branch target injection". Omdat het erg lastig is om code patronen te vinden die geschikt zijn voor Variant 1, kan je ook proberen om te forceren dat de processor speculatief een specifiek stuk code uitvoert. Dit is gebaseerd op Return Oriented Programming (ROP) technieken; je zoekt naar bepaalde instructie sequences in een bekende binary (bijvoorbeeld libc), en probeert te forceren dat de code daar naartoe springt op het speculatieve pad. Dit kan gedaan worden door de BTB aan te vallen; deze zit helemaal voorin de processor pipeline in het Fetch gedeelte en probeert te voorspellen waar een indirecte branch heen zal springen. Door deze voor dat branch adres te trainen dat hij naar een verkeerd adres springt, kan je deze aanval uitvoeren. Waarschijnlijk is deze aanval vrij moeilijk omdat de BTB maar een kleine capaciteit heeft, dus de kans dat je speciaal geprepareerde state vervuild is voordat de aangevallen code deze branch bereikt is aanzienlijk.

Wat is hier aan te doen?
De beste oplossing is natuurlijk om dit allemaal op te lossen op micro-architectuur niveau; maar dat betekent een aantal jaar wachten op een nieuwe generatie processors waar dit in gefixed is. De false-sharing effecten binnen de BP en BTB waarbij twee verschillende contexten elkaar beinvloeden zou op te lossen zijn door deze data structuren een address space/process ID toe te voegen, zodat er geen aliasing meer ontstaat. In feite levert dat een sterkere scheiding op micro-architectureel niveau op tussen verschillende software contexten. Voor Meltdown zou een micro-architecturele aanpassing gemaakt moeten worden zodat de speculatieve privilage violation geen geldige data aan opvolgende instructies levert. Ook zou een betere MMU scheiding tussen hyperprivileged, kernel en user helpen.

Maar goed, dat is niet echt iets wat op de korte termijn werkt. Voor Meltdown hebben ze nu OS patches gebaseerd op het KAISER onderzoek; door de kernel page tables te unmappen als je in userspace bent, kan een dergelijk speculatieve instructie uberhaupt nooit bij het kernel geheugen komen omdat er geen translatie voor beschikbaar is. Dat kost wat performance, en zoals ik al eerder aangaf, bewijfel ik of dat werkt. (Zie laatste alinea van: Squee in 'nieuws: Intel ontkent berichten dat alleen zijn processors vatbaar ... ). Ik heb nog contact gezocht met Werner Haas (een van de onderzoekers) en het hier over gehad, en hij was van mening dat dat inderdaad best mogelijk zou kunnen zijn, en dat ze het zeker verder gaan onderzoeken na alle patches beschikbaar zijn gemaakt en uitgerold.

Voor de Spectre BTB aanval lijken ze nu patches te maken in de Linux kernel om indirecte branches non-speculatief te maken, simpelweg door er een barrier tussen te gooien. Dat is een vrij pijnlijke oplossing, al weet ik niet goed in te schatten hoeveel performance dit zou kosten. Voor de BP aanval heb ik nog geen duidelijke oplossing gezien.

Er zijn ook nog wel een aantal heel erg pijnlijke maatregelen die genomen zouden kunnen worden, zoals het compleet uitschakelen van branch prediction. Ik vind het lastig in te schatten wat voor performance effect dat zal hebben, maar dat zal *enorm* zijn. De vuistregel is dat ongeveer een in de vijf instructies een branch is, en als je dan regelmatig een 50+ cycle flush moet doen omdat een branch toch genomen moest worden... ouch, daar gaat je performance. Er zou ook in theorie een micro-code update kunnen komen die alle branches, en/of alle indirecte branches een barrier effect geeft, zodat er niet voorbij gespeculeerd kan worden. Dit zou ook een enorm performance effect hebben.

Ik ben heel erg benieuwd wat voor informatie we de komende dagen zullen krijgen over hoe de verschillende bedrijven dit op gaan lossen.
1 2 3 ... 6

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True