VU Amsterdam ontdekt nieuwe Spectre-kwetsbaarheid die Intel- en Arm-cpu's treft

Securityonderzoekers van de Vrije Universiteit in Amsterdam hebben een nieuwe Spectre-kwetsbaarheid ontdekt. Die kwetsbaarheid treft veel moderne Intel-processors en bepaalde Arm-cpu's. Beide bedrijven komen met beveiligingsupdates die het probleem moeten oplossen.

De beveiligingsonderzoekers noemen de aanval Branch History Injection, oftewel BHI of Spectre-BHB. Het is een nieuwe variant van de bestaande Spectre-V2-kwetsbaarheid. De onderzoekers hebben een proof of concept exploit gemaakt waarmee ze het kernelgeheugen van moderne Intel-cpu's kunnen onderscheppen. In een video weten de onderzoekers bijvoorbeeld een root entry te laten uitlekken op een systeem met een Intel Core i7-10700K. Ook bepaalde Arm-cpu's worden getroffen, hoewel de kwetsbaarheid geen impact lijkt te hebben op AMD-processors, schrijft Phoronix.

BHI kan hardwarematige mitigaties voor Spectre-V2, zoals eIBRS en CSV2, omzeilen. Via de nieuwe kwetsbaarheid kunnen hackers eigen predictor entries injecteren in de global branch prediction history en daarmee kernelgegevens laten uitlekken.

Intel heeft een complete lijst gepubliceerd met processors die kwetsbaar zijn voor Spectre-BHB. Daaruit blijkt dat alle chips die het bedrijf sinds 2013 heeft uitgebracht, kwetsbaar zijn; de lijst begint met de Haswell-generatie en ook de recente Alder Lake-cpu's voor consumenten en Ice Lake-serverprocessors staan op de lijst. Intel brengt beveiligingsupdates en mitigaties voor de kwetsbaarheid uit. Die zijn bijvoorbeeld al doorgevoerd in Linux-kernelversie 5.16 en met terugwerkende kracht aan oudere kernelversies toegevoegd.

Verschillende Arm-cores zijn ook kwetsbaar, waaronder Cortex A15-, A57-, A78-, X1- en X2-kernen, die bijvoorbeeld worden gebruikt in smartphones. Ook Neoverse N2-, Neoverse N1- en V1-cores voor servers en hpc-doeleinden zijn kwetsbaar. Arm komt ook met updates die de problemen moet mitigeren. AMD-chips lijken niet getroffen te zijn. De Intel-kwetsbaarheden worden gevolgd op CVE-2022-0001 en CVE-2022-0002. Arm gebruikt CVE-2022-23960.

Reacties (58)

[Onno]

In een video weten de onderzoekers bijvoorbeeld een root entry te laten uitlekken

Een "root entry" zonder context betekent niks. In de titel van de video, en in het gelinkte Phoronix-artikel staat het beter:

root entry in /etc/shadow

The BHI proof of concept from VUSec is used to leak root entry data from /etc/shadow

Het gaat erom dat ze een regel uit het bestand met wachtwoordhashes van lokale gebruikers te pakken hebben gekregen terwijl dat bestand, /etc/shadow, niet leesbaar zou moeten zijn. Dat het in hun proof of concept nou toevallig om de gebruiker "root" ging is niet het belangrijkste.

[Reactie gewijzigd door Onno op 23 juli 2024 13:38]

[Weicool]

Ik heb hun vak Hardware Security aan de VU gezien waarin ze dit soort dingen in detail uitleggen. Je moet dan continu op behoorlijk onrealistische manier het wachtwoord bestand in cache laden om het eruit te kunnen halen met deze aanval.

Het lijkt dus meer puur onderzoek dan echt iets dat je kan gebruiken om iemand anders mee te hacken: wat denken jullie daar als tweakers over?

[sdsnatcher73]

Het gaat er niet zozeer om hoe makkelijk je nu het root wachtwoord achterhaald. Waar het om draait is dat het dus lukt om geheugen te lezen waar je niet bij mag. Op onze machientjes thuis niet enorm spannend, maar doe je het op een server bij de cloudboeren kun je dus ook data inzien die van een andere klant is (op een heel andere vm).

[hejkompas]

In de video lijken ze passwd te gebruiken om de shadow in het geheugen te laden. Dat is niet onrealistisch en werkt in praktijk.

[Weicool]

Hun gebruikelijke setup was echter: nog meer privileges voor passwd voor normale gebruikers uitschakelen, dan de mogelijkheid om wachtwoorden voor normale gebruikers te gebruiken ook uitschakelen zodat alleen privesleutels gebruikt kunnen worden voor normale gebruikers, dan weer een script met andere privileges gebruiken om als normale gebruiker passwd te kunnen aanroepen…

En dat allemaal bij elkaar roept natuurlijk vragen op over hoe realistisch het zou kunnen zijn als jij als externe hacker op een willekeurige computer zonder eerder al een of andere vorm van toegang te hebben dan nog steeds zo’n Root wachtwoord zou kunnen achterhalen met deze methode.

[Reactie gewijzigd door Weicool op 23 juli 2024 13:38]

[casberrypi]

Praktische toepassingen laten we over aan de Israëli's. Ga er maar van uit dat die er al een wapen van hebben kunnen maken.

[Kusanagi]

Ik ben altijd behoorlijk onder de indruk van het niveau waarmee mensen naar kwetsbaarheden zoeken en ze soms ook daadwerkelijk vinden. We hebben het hier nog over de universiteit. Benieuwd wat er gebeurd wanneer deze monsters in het werkveld terecht komen... prachtig.

[svennd]

Het zijn Ph.D's an Postdocs, dat valt al onder "werkveld"

[bbob]

Ga er ook maar van uit dat er mensen zijn die dit soort kwetsbaarheden als zero-day verkopen zodat ze door geheime diensten en dergelijke ge/misbruikt kunnen worden.

Maar je moet idd veel verstand van zaken hebben, creatief zijn om dit te vinden.

[Weicool]

Zoals hierboven uitgelegd: niet realistische aanvallen om iemand mee te hacken: puur wetenschappelijk onderzoek

[Alfa1970]

Er is m.i. specifiek en uitsluitend alleen onderzoek gedaan naar dit specifieke type vulnerability en men heeft variaties van het thema gebruikt om iets "nieuws" te vinden.

Dit was m.i. niet een generiek onderzoek naar kwetsbaarheden in het algemeen, maar "slechts" een onderzoek of er nog varianten te bedenken waren op het bestaande thema.

Neemt niet weg dat het een knap staatlje werk is, maar het is een veld waarin je van te voren redelijkerwijze kunt voorspellen dat je iets zal vinden omdat je van te voren weet dat het erin zit.

[ruftman]

Mag ik verbaasd zijn dat ook de Alder lake processoren hierdoor worden getroffen? Ik dacht dat Intel dit met een nieuwe processorarchitectuur wel aangepakt zou hebben (meer ook ik weet dat elke processor wel bugs en lekken bevat).

[Verwijderd]

Ik las laatst een artikel dat, de PR afdeling van Intel van mening was "veiligere" CPU"s te hebben dan AMD. Toch blijkt ook nu weer dat AMD totaal niet getroffen werd in bovenstaande hack.

Heel Intel met branche prediction is zo lek als een zeef, en met alle fixes kampt men nog steeds met performance:

https://www.tomshardware....ad-ridl-fallout,6146.html

https://www.tomshardware....cloud-services,36326.html

https://www.tomshardware....tch-benchmarks,36317.html

Het is niet voor niks waarom grotere cloud bedrijven zoals Google, Amazon en weet ik het wat tegenwoordig steeds vaker voor AMD Epyc's kiezen. Die hebben niet zo'n last van zulke performance hits. Voor een consumentenbak maakt het weinig uit een patch hier en daar, echt hele specifieke gevallen, maar een rack vol met servers / Intel CPU's kan gewoon 10 tot 30% van je totale performance gaan kosten.

[CivLord]

Wat ook meespeelt is dat AMD over het algemeen de meeste bang-for-the-buck levert, zolang je niet de absolute top-performance eist.

[kiang]

Euh?

Voor servers biedt AMD net de absoluut beste performance. Intel's chips zijn heter en hebben minder cores. Wat er toe doet voor datacenters (zo vele mogelijk performance per oppervlak en Watt) daar scoort AMD net geweldig, Intel helemaal niet om dit moment.

[Z100]

Je bent niet de enige. Ik dacht dat alles weer op orden zou zijn met Intel sinds Alder Lake, maar m'n aanstaande systeem neig ik toch weer richting AMD. Rembrandt heeft betere accuduur dan Alder Lake, en zou mij niets verbazen dat het qua security ook beter is ontworpen. Ik bedoel Alder Lake is nog geen maand op de markt, en men vindt nu al weer een kwetsbaarheid.

[Alfa1970]

Je moet jezelf wel bedenken dat het ontwerpen van deze complexe CPU's niet een proces is van een paar weken.
Een radicale verandering in een ontwerp waar al meer dan 20 jaar op wordt gebouwd doe je niet zo maar eventjes. Dat is nog vooropgesteld dat de kennis om dergelijk fundamentele aanpassingen te maken uberhaupt nog aanwezig is.

[MSalters]

"Radicale verandering"?

Het gaat hier om een cache-probleem. Dat is extreem transparant voor de meeste software. Sterker nog, de meeste software beseft niet eens hoeveel soorten cache er is, of wat de overlap is tussen die verschillende caches. Intel heeft vrijwel onbeperkte vrijheid om caching te wijzigen.

[Alfa1970]

Om het probleem te verhelpen moet er een andere architectuur voor de cache worden gebruikt.
Hetgeen dus onder het hoofdstuk radicale verandering valt.
Het is een hardware probleem, dus wat software zoals jij het omschrijft daarmee te maken heeft snap ik niet zo goed.
Of wil je beweren dat het fixen van het hardware probleem triviaal is en zeer simpel in te passen is in het ontwerp van een CPU waar gemiddeld 5 jaar aan wordt gewerkt?

[Reactie gewijzigd door Alfa1970 op 23 juli 2024 13:38]

[MSalters]

Als je elke transistor aan verandering al "radicaal" noemt, ja. In dit specifieke geval is het voldoende om te branch predictor cache te togglen tussen user en kernel mode. Twee modes, twee standen van de schakelaar.

En "5 jaar"? Dan heb je duidelijk geen idee hoe lokaal zo'n wijziging is. Je kunt die hele cache uitschakelen en dan blijft je CPU nog werken. Maar de wijziging die ik voorstel is veel minder radicaal. Elke cache heeft een cache key van een paar bits. Ik stel voor om 1 bestaande bit (user/kernel mode) te gebruiken in die cache key.

[CivLord]

Het is een kwetsbaarheid van de architectuur die Alder Lake deelt met zijn voorgangers.
AMD zal ongetwijfeld vergelijkbare kwetsbaarheden hebben die gevonden kunnen worden wanneer er maar goed genoeg naar gezocht wordt (of die al gevonden zijn, maar niet bekend gemaakt zijn).

[locke960]

Mij verbaast het niet. Intel heeft over een langere tijd fundamentele ontwerpkeuzes gemaakt die dit soort kwetsbaarheden mogelijk maken. Dat werkt lang door. Nieuwe processorgeneraties zijn een evolutionaire vooruitgang waarbij je voor een groot deel aan die eerder gemaakte keuzens vast zit*. Anders zou het ten koste gaan van compatibiliteit en/of performance en dat wil Intel niet. En wij waarschijnlijk ook niet, als we eerlijk zijn.

*De marketing afdeling wil ons natuurlijk wel graag doen geloven dat elke nieuwe generatie een revolutionaire verandering is.

[ruftman]

Ik zal wel afwijkend zijn, maar ik vind het niet erg om performance in te leveren als de processor daardoor veiliger wordt. De meeste multicore processors zijn toch snel genoeg om alle applicaties vlot te draaien.

[me23]

Dit is voor gebruikers niet zo'n probleem omdat die meestal hun pc niet delen.

In datacenters en cloud is dit wel een probleem omdat je zoveel mogelijk resources wilt delen met zoveel mogelijk gebruikers en dat zo veilig mogelijk.

Nu kan het dus zo zijn dat je de helft aan resources moet inleveren om het veilig te maken.

[CivLord]

Compatibiliteit wordt gegarandeerd door de instructieset, niet door de architectuur van de processor.

De keuze van Intel wordt ingegeven door de resources die nodig zijn om een nieuwe (of drastisch vernieuwde) architectuur te ontwerpen. Is het theoretisch mogelijk om elke twee á drie jaar een nieuwe (vernieuwde) architectuur te ontwerpen die beter is dan de vorige? Vast wel, maar te duur om praktisch haalbaar te zijn. Het is economisch veel praktischer om en architectuur in een paar te ontwikkelen en daarna elk jaar verder te fine-tunen en te verbeteren voordat je, wanneer het duidelijk wordt dat alle mogelijkheden van een bepaalde architectuur wel zo'n beetje benut zijn, begint met het ontwikkelen van de opvolger.

[Gadget Freak]

Hoe zit het met de kwetsbaarheid van de Apple Ax en M1 processoren?

[Pinkys Brain]

Geen idee maar totdat Apple terugstapt in de server space is het voor Apple devices veel minder relevant, tenzij het werkt in javascript (waar high resolution timers tegenwoordig verwijderd zijn, wat het moeilijk maakt).

[PjotterP]

er is meer dan alleen servers. Denk aan workstations.

[Pinkys Brain]

Sorry, ik ging wat kort door de bocht.

Een desktop, hoe professioneel ook is over het algemeen in gebruik door of een persoon of personen die met elkaar vertrouwt zijn (javascript even daargelaten). Iemand kan malware installeren die via spectre een password jat, maar je hebt dat voor een groot deel zelf in de hand.

De grootste impact van spectre&co is op cloud providers, isolatie is hun levensbloed.

[PageFault]

Interessante vraag met de ARM architectuur.

[Luchtbakker]

ARM is een architectuur, waar ook Apple gebruik van maakt. Dus de kans is groot dat die dat ook heeft.

[_Pussycat_]

x86-64 wordt ook door AMD gebruikt maar die zijn niet kwetsbaar. De kans is dus groot dat Apple dit probleem ook niet heeft.

[wiseger]

Zoals eerder al gemeld door diverse Tweakers, Spectre is een security risico bij cloud servers. Daar mag klant A nimmer bij de data van klant B.
Op lokale PC's heeft het weinig impact omdat de aanvaller dan al toegang tot de PC moet hebben om zijn aanval te kunnen draaien.
Aangezien Apple geen servers levert voor data centers, zijn ze niet relevant voor dit soort dreigingen.

[Havelock]

Dat vroeg ik me ook al af of Apple met hun processors arm soc’s in hun apparaten hier ook last van heeft(bug)!
En bij Intel processors komt daar dan een software update als daar ook die bug in zit!

[Frogmen]

Wat ik mis in het verhaal ik snap dat als je toegang hebt dan het root wachtwoord kan achterhalen, maar dan moet je wel eerst toegang hebben. Anders gezegd hoe reeel is het dat dit in het wild ook daadwerkelijk misbruikt kan worden. Dat is namelijk wat ik zelf boeiend vindt.

[MetalfanBlackness]

Iets installeren op iemand zijn computer is meestal niet het probleem. Kijk wat voor programma je doelgroep wil en zet het online, zoals bijvoorbeeld een LHR hash limit remover. Dit helpt je om meer te mogen op het systeem

[laurxp]

Het gaat altijd om ketens van kwetsbaarheden.

Stel, er zit bijvoorbeeld in de service voor printers delen een bug die Remote Code Execution mogelijk maakt. Op zichzelf bijna onschuldig, want die service draait onder een account dat nul rechten heeft.
Met deze nieuw ontdekte bug kan je ineens willekeurige bestanden lezen, dus ook bijvoorbeeld de SSH private keys van de gebruiker van die machine - die wellicht zelfs de systeembeheerder is.
Niet iedereen versleutelt deze, dus nu heb je ineens toegang tot de servers van dat bedrijf - hoewel zonder veel rechten.
Gooi een executable op de server die bij het uitvoeren van "sudo" door die gebruiker het wachtwoord onderschept (hier heb je geen speciale rechten voor nodig).
Trigger een Denial of Service op de server, en de admin zal waarschijnlijk inloggen en "sudo" uitvoeren.
En nu heb je ineens roottoegang tot alle servers van dat bedrijf!

Iedere bug die voor extra vaardigheden of rechten kan zorgen is dus per definitie een veiligheidsprobleem, ook al zijn ze individueel niet heel nuttig.

[BCC]

Je zou in de toekomst dan kunnen denken aan bijvoorbeeld een VPS bij een hoster waar je root toegang toe kan krijgen vanuit je wordpress omgeving.. of inderdaad zoals hierboven vanuit "keygen.exe"

[.oisyn]

Maar dit (deze klasse van bugs iig) heeft ook impact op sandboxed omgevingen die onvertrouwde gedownloadde code runnen. Denk aan javascript in je browser.

[wiseger]

Zoals al eerder uitgelegd, het is een probleem voor data centers. Tegenwoordig staat bijna alles in de Cloud. Hier geldt dat men d.m.v. virtualisatie de boel gescheiden houdt.
Gedachte experimentje: normaliter kan de Chinese inlichtingendienst niet bij de servers van ASML komen, ook al zorgen ze ervoor dat ze met een nep bedrijf in hetzelfde data centers terecht komen als ASML en dus wellicht op dezelfde fysieke servers. Met Spectre kunnen ze dat wel, klant A kan toegang krijgen tot de data van klant B op dezelfde fysieke server.

[Hee_Martijn]

Hoe kan het nou dat deze kwetsbaarheid op totaal verschillende architecturen werkt? Ik bedoel arm en x86 zijn toch totaal verschillend? Risc vs Cisc, andere assembly taal etc, etc.

[MSalters]

Terechte vraag.

Ten eerste zijn de getroffen Intel architecturen allemaal RISC, net zoals ARM. Intel is na de originele Pentium (P54/P55) gestopt met CISC cores. En alhoewel x86 en ARM verschillende nummers gebruiken voor de branch c.q. jump instructies, hebben beide wel dezelfde soort jump instructies. In het bijzonder heeft AArch64 tegenwoordig hetzelfde soort conditionele branches als x86, waar ARM klassiek conditionele instructies gebruikte. En aangezien de patenten voor branch prediction grotendeels verlopen zijn, heeft ARM tegenwoordig dus ook predicted branches.

Wat er dus nu blijkt, is dat deze predictions bij ARM en Intel op dezelfde manier te herkennen zijn (via timing), en op dezelfde manier lekken vanuit kernel-code (niet gereset na user-mode switch).

[Hee_Martijn]

Duidelijk, bedankt!

[Grert]

Hoe zit het met apple sillicon??

[EmperorBaal]

Volgens de website van Intel valt mijn I7-4820k niet onder de kwetsbare processoren. Ik kan deze niet vinden op beide lijsten. Zou de Ivy Bridge E architectuur hier buiten vallen?

[Toettoetdaan]

Volgens mij is die lijst alles wat ze in en na 2018 verkochten. Dus waarschijnlijk gaat het ook om chips van daarvoor. Eigenlijk alles met Intel, SMT en branch prediction zou hier voor moeten vallen.

[EmperorBaal]

Ja dat lijkt mij ook logisch dat de mijne ook kwetsbaar zou zijn. Ik was op de lijst aan het zoeken op 4820 en de E7-4820 kwam er wel in voor, en dat is ook een oud beestje alhoewel een Xeon die waarschijnlijk nog veel vaker gebruikt wordt. Vandaar mijn verwarring.

[N8w8]

Dit is vziw de laatste versie waar jouw CPU nog in voorkomt.
Daar staat deze nieuwe kwetsbaarheid natuurlijk niet bij, maar goed.

[peverix]

Is pas vanaf Haswell en Ivy Brigde is van daarvoor.

[MattiVM]

Intel brengt beveiligingsupdates en mitigaties voor de kwetsbaarheid uit. Die zijn bijvoorbeeld al doorgevoerd in Linux-kernelversie 5.16 en met terugwerkende kracht aan oudere kernelversies toegevoegd.

Komen die beveiligingsupdates binnen via de updates van het OS of moet men zelf nog actie ondernemen (zoals bios update of zo)?

[SunnieNL]

Meestal eerst via OS updates (die een virtuele layer om de cpu leggen) en daarna in de vorm van een bios update.

[Henk Poley]

De 'retpoline' pleister, is er een van het besturingsysteem.

Mochten Intel & AMD toch nog met een truc komen, dan worden ook Microcode updates via een driver ingeladen steeds bij het opstarten van de computer. Een UEFI BIOS update verandert enkel dat de microcode update nog ietsje eerder ingeladen wordt.

[Ryan1981]

Is er al bekend of de fix gepaard gaat met prestatie verlies?

Ik meen mij te herinneren dat spectre met name op hyperthreading CPU's een probleem was en dat mijn i9700k daar geen last van had (heeft geen hyperthreadig) en dat hyperthreading cpus door de fix prestatieverlies hadden. Maar nu zie ik die van mij er ook tussen staan. Misschien haal ik kwetsbaarheden door elkaar.

[Soldaatje]

Onder Linux draai ik met boot optie

mitigations=off

op eigen risico uiteraard.
Dan heb je geen prestatieverlies hierdoor.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 13:38]