Er zit een fors lek in een groot deel van alle cpu's. Net als bij Meltdown en Spectre is er veel ophef rondom deze kwetsbaarheid, maar nu gaat het ook om hardwarematige eigenschappen van de chips. Betekent dit lek het einde van Hyper-Threading?
Wat gebeurde er ook alweer?
Eerder deze week brachten verschillende beveiligingsonderzoekers een ernstig lek aan het licht dat vrijwel iedere cpu van Intel treft. Dat kwam als een onaangename verrassing, want de cpu's van dat bedrijf zitten in meer dan driekwart van alle computers ter wereld.
Het gaat niet om één lek, maar om verschillende kwetsbaarheden, die min of meer gelijktijdig werden ontdekt door verschillende onderzoeksteams. De eerste werd ontdekt door Nederlandse onderzoekers van de Vrije Universiteit Amsterdam, maar onderzoekers van de KU Leuven vonden een soortgelijk lek, net als wetenschappers van de Universiteit van Graz in Oostenrijk. Intel schaart alle drie de aanvallen onder dezelfde kwetsbaarheid, omdat ze van dezelfde zwakke plekken in cpu's gebruikmaken. De onderzoekers hebben ook verschillende websites opgezet met hun bevindingen en whitepapers gepubliceerd. Ook Intel heeft dat gedaan, met een algemene blogpost. Zij noemen de bugs onder één verzamelnaam: Microarchitectural Data Sampling, of MDS. De onderzoekers hebben ook verschillende namen aan de kwetsbaarheden gegeven.
Onderzoekers | Naam van lek | Website |
VU Amsterdam (VUsec) | Rogue InFlight Data Load (RIDL) | MDSattacks.com |
KU Leuven | Fallout | MDSattacks.com |
Universiteit van Graz | Zombieload | Zombieloadattack.com / CPU.fail |
Intel | Microarchitectural Data Sampling (MDS) | Intel.com |
Om wat voor kwetsbaarheden gaat het?
De kwetsbaarheden zitten in speculative execution, een optimalisatiemethode waarbij een cpu bepaalde taken of berekeningen probeert te voorspellen om de processor sneller te maken. Als zo’n voorspelling uitkomt, kan de berekening eerder worden uitgevoerd doordat de data dan al eerder geladen werden. Als de voorspelling niet klopt, wordt die weggegooid. Voor het maken van zulke voorspellingen worden verschillende soorten buffers gebruikt, zoals line-fill buffers, die data in de cache laden, en store buffers, die data naar het gewone geheugen schrijven. Met de nu ontdekte kwetsbaarheid kunnen de onderzoekers de data die weggegooid hadden moeten worden, uit die buffers onderscheppen.
Een aanvaller kan echter niet zomaar bepalen welke data hij uit een buffer kan aflezen. In een proof-of-concept van de VU laten de onderzoekers zien hoe ze een wachtwoord uit een Linux-partitie kunnen halen. Ze moeten de nodige commando's heel vaak draaien voordat ze de juiste data uit de buffer kunnen halen. Dat proces duurde ook lang: zo'n 24 uur. Mede daarom relativeert Intel de kwetsbaarheid. "Praktische uitbuiting van MDS is erg complex", schrijft Intel in een verklaring. "Maar", voegen de onderzoekers toe, "dat was onder de proof-of-concept. We kunnen het verder optimaliseren zodat het al binnen enkele minuten kan." Nadat de beveiligingsonderzoekers het lek aan Intel hadden gemeld, kwam de fabrikant met een microcode-update. Op basis daarvan hebben verschillende fabrikanten een patch uitgebracht.
Dat er in één keer verschillende lekken zijn gevonden, komt door het verschil tussen de soorten buffers die kunnen worden afgeluisterd. “Wij presenteerden aan Intel een proof of concept om te lekken uit line-fillbuffers en load ports”, vertelt Stephan van Schaik, een van de onderzoekers van de VU aan Tweakers. “Toen we daarover in gesprek raakten met Intel, kwamen we erachter dat het lek ook kon worden uitgebuit via load ports of storebuffers. Van dat laatste weten we niet honderd procent zeker of ons proof of concept ook daarop van toepassing is; dat onderzoeken we nog.” Dat storebufferlek is weer waar Zombieload op is gebaseerd: het lek dat de Oostenrijkse onderzoekers ontdekten, maar ook Fallout.

In hoeverre lijkt dit lek op Spectre en Meltdown?
De kwetsbaarheid doet in eerste instantie veel denken aan twee andere grote cpu-bugs: Spectre en Meltdown. Die kwamen in januari vorig jaar met veel ophef naar buiten en niet zonder reden. Via die kwetsbaarheden kon informatie direct uit het geheugen van de chips worden ontfutseld en in beide gevallen ging het om een probleem dat niet zomaar te patchen was. En, niet onbelangrijk: bij zowel MDS als bij Meltdown ging het specifiek om Intel-chips (al werd ook de ARM Cortex A75 door Meltdown getroffen).
Wel zitten er een paar fundamentele verschillen tussen MDS enerzijds en Meltdown en Spectre anderzijds. In het geval van Meltdown ging het bijvoorbeeld om informatie die uit het kernelgeheugen kon worden gelezen. Bij MDS wordt de informatie uit verschillende soorten buffers van de chip geplukt. Daar zit volgens de onderzoekers een van de fundamentele verschillen; het gaat hier om een lek van in-flight data, gegevens die actief worden gebruikt tijdens een sessie, en niet om data die in het geheugen of in een cache zijn opgeslagen.
Ook zit er verschil in de manier waarop je data kunt aflezen. Van Schaik: “Bij aanvallen zoals Meltdown was dat veel gerichter. Daar kon je heel specifiek wijzen naar een adres, naar een specifieke plek in de kernel. RIDL richt zich niet specifiek op een dergelijke plek, maar op alle informatie uit de buffer. Die kun je dan aftappen en kijken wat erin zit, en dat maakt het heel moeilijk om hier op softwaregebied iets tegen te doen.”

Betekent dit het einde van Hyper-Threading?
Wat het lek een stuk gecompliceerder maakt, is de relatie met simultaneous multithreading, of smt, een proces waarbij een fysieke core wordt gevirtualiseerd naar meerdere logische cores om zo meerdere threads op één core uit te voeren. Intels variant daarvan heet Hyper-Threading en dat proces maakt deze kwetsbaarheid makkelijker uit te buiten. Een update van de microcode vanuit Intel lost dat probleem enigszins op, maar niet helemaal, zegt Van Schaik. “De nieuwe microcode geeft ontwikkelaars van besturingssystemen een barrière. Die zorgt ervoor dat data in de buffers vóór de barrière niet gelekt kunnen worden door code ná de barrière. Dus als je wisselt van applicaties, kan het oude proces het nieuwe niet uitlezen tijdens speculative execution. Zo kun je dus via onze methode ook niets meer aflezen. Maar wanneer je Hyper-Threading aan laat staan, kun je niet voorkomen dat die barrière op beide threads geforceerd wordt. Daarom is het het veiligst om Hyper-Threading maar uit te schakelen.”
Het is niet voor het eerst dat Hyper-Threading wordt genoemd als potentieel veiligheidsrisico. Zo werd het proces in openBSD al eerder uitgeschakeld, omdat type libraries en L1-caches uitgewisseld werden tussen threads en die potentieel te onderscheppen waren. Ook Google heeft maatregelen genomen door Hyper-Threading uit te schakelen in ChromeOS 74, de recentste versies van het besturingssysteem. Toekomstige versies ervan krijgen 'extra maatregelen', al is niet direct duidelijk welke dat zijn. Gebruikers kunnen het proces wel nog handmatig inschakelen.
Andere softwaremakers, zoals Apple, Microsoft en verschillende Linux-distributies, komen met een patch die aanvallen via JavaScript en de browser onmogelijk maken. Er is een update voor Windows beschikbaar. Apple heeft macOS Mojave 10.14.5 uitgebracht, maar die is er niet voor iedere Macbook of iMac, doordat Intel daarvoor geen microcode-update heeft uitgebracht.
De bedrijven én de onderzoekers raden zelf ook aan om Hyper-Threading handmatig uit te schakelen. Die maatregel is nogal heftig en kan in sommige systemen leiden tot een flinke daling van prestaties, maar om hoeveel dat precies gaat, is moeilijk te zeggen. Dat verschilt per systeem en per programma; verschillende ontwikkelaars zijn inmiddels bezig met benchmarks. Intel waarschuwt dat de totale performance hit kan oplopen tot wel veertig procent, al zal dat vooral in extreme gevallen zijn.
Het probleem van het lek
Google erkent dat probleem. "De beslissing om Hyper-Threading aan of uit te zetten is een afweging tussen veiligheid en performance." Er zijn op dit moment nog geen officiële benchmarks beschikbaar die het verschil in prestaties met en zonder de microcodepatch laat zien, een verschil dat in elk geval per applicatie en configuratie anders zal zijn. Dat bevestigt Van Schaik ook. “We hebben zelf geen cijfers over het performanceverlies, maar je kunt wel schatten wanneer Hyper-Threading vooral winst kan opleveren. Het hangt af van je workload; bij serverapplicaties is het bijvoorbeeld nuttig. Daar heb je veel clients die verbinden en zolang je niet met veel caches werkt en weinig responses hoeft te sturen, is dat prima. Als je echter veel data in een cache hebt, bijvoorbeeld bij het verwerken van grote databases, dan heb je niet zoveel aan Hyper-Threading. En bij gaming is single clock speed ook meestal het relevantst.” Bovendien, voegt hij toe, is het maar de vraag of de oplossingen die Intel voorstelt niet juist leiden tot slechtere prestaties dan wanneer Hyper-Threading helemaal wordt uitgeschakeld.
is dat het om een hardwarekwetsbaarheid gaat
Intel raadt het uitschakelen van Hyper-Threading officieel niet aan, maar noemt het het wel als mogelijke maatregel in een nadere analyse van het probleem. "Enkel het uitschakelen van HT beschermt niet tegen MDS", schrijft het bedrijf. Het laat de beslissing aan klanten zelf. Intel heeft de vier kwetsbaarheden zelfs ingeschaald op het niveau 'laag tot middelmatig'.
Wanneer ben ik kwetsbaar?
De grootste impact van de kwetsbaarheid zit in twee dingen: het feit dat het om een hardwarematige bug gaat, die dus niet zomaar te patchen is, en de wijdverspreidheid ervan. Het lek zit namelijk in vrijwel iedere cpu van Intel. Alle chips van Intel vanaf 2008 zijn kwetsbaar; het gaat om chips met een architectuur vanaf Nehalem. De kwetsbaarheid zit niet alleen in cpu's voor laptops en desktops, maar ook in de Xeon-processors voor servers. AMD- en ARM-chips zijn niet kwetsbaar voor de kwetsbaarheid. AMD heeft daarover ook een verklaring naar buiten gebracht.
De onderzoekers van de VU Amsterdam hebben op hun website een tool gezet waarmee kan worden gecontroleerd of een systeem kwetsbaar is voor MDS.

Er is niet veel nodig om de kwetsbaarheid te misbruiken. Een aanvaller kan dat al als hij toegang heeft tot een machine of het netwerk van een computer, bijvoorbeeld door op hetzelfde netwerk te zitten in een kantooromgeving. Het is ook mogelijk code uit te voeren met JavaScript via bijvoorbeeld een geïnfecteerde website. Van Schaik: “Een aanvaller hoeft eigenlijk alleen maar unprivileged code access te hebben tot een machine. Het helpt dan ook niet om bijvoorbeeld met virtuele machines of secure enclaves te werken, want die maken gebruik van dezelfde onderliggende infrastructuren.”
En nu?
De grote vraag is nu hoe kwetsbaar gebruikers daadwerkelijk zijn. In eerste instantie lijkt het lek ernstig: een veelgebruikte technologie in vrijwel iedere cpu van zowel servers als desktops blijkt kwetsbaar en er is veel gevoelige informatie te stelen. Van de andere kant is een aanval uitvoeren niet zo makkelijk. Je moet daarvoor binnen hetzelfde netwerk zijn als een kwetsbare computer of een malwareaanval uitvoeren zoals via een banner op een website.
Hopelijk bieden in het verleden behaalde Meltdown-resultaten garantie voor de MDS-toekomst. Sinds die bug immers samen met Spectre en Foreshadow openbaar werd gemaakt, zijn er vrijwel geen grootschalige aanvallen met die methode voorgekomen. Die werden door sommige beveiligingsonderzoekers wel voorspeld. Voorlopig lijkt MDS ook redelijk goed in toom te houden. Met updates aan besturingssystemen worden grote risico's zoals JavaScript remote code executions tegengehouden en door Hyper-Threading uit te schakelen is het risico goed te minimaliseren. Of de risicoreductie opweegt tegen de daling in prestaties, is een andere vraag.