Intel verwacht dat software en dram kunnen beschermen tegen Spoiler-lek - update

Intel heeft een reactie gegeven op het verschijnen van Spoiler, een manier om bij Intel-systemen efficiënter Rowhammer-aanvallen uit te voeren om geheugen uit te lezen. Intel denkt dat software en beschermde dram aanvallen kunnen voorkomen.

Dram-modules die bescherming bieden tegen Rowhammer, beschermen ook tegen Spoiler en als bij de ontwikkeling van software bescherming tegen sidechannelaanvallen is toegepast, helpt dat ook tegen aanvallen. Dat maakt Intel bekend in een verklaring aan The Register.

Die site schreef dinsdag over het Spoiler-lek, dat door onderzoekers van het Amerikaanse Worcester Polytechnic Institute en de Duitse Universiteit van Lübeck is aangetroffen in Intel-cpu's. De onderzoekers hebben tien processors van Intel getest, van de Nehalem- tot de Kaby Lake R-generatie, die allemaal kwetsbaar waren. Een Qualcomm Kryo 280 op basis van ARM v8 en een AMD A6-4455M op basis van de Bulldozer-architectuur bleken niet vatbaar voor Spoiler.

Het gaat niet zozeer om een nieuwe aanval, maar om een methode waarmee Rowhammer-aanvallen efficiënter uit te voeren zijn en die tot nieuwe typen aanvallen kan leiden. De onderzoekers richtten zich op de Memory Order Buffer, die door het speculatief laden van waardes informatie over fysieke geheugenadressen laat uitlekken. Ook de bekende Spectre- en Meltdown-kwetsbaarheden gebruiken de 'speculatieve' operaties van cpu's om aanvallen te kunnen uitvoeren.

De onderzoekers gebruiken het uitlekken van fysieke geheugenadressen om Rowhammer- en cacheaanvallen te versnellen. Die aanvallen berusten op het reverse engineeren van de wijze waarop virtuele geheugenadressen in fysieke adressen zijn omgezet. Met behulp van Spoiler is dat reverse engineeren met een factor 256 te versnellen volgens de onderzoekers. Een aanval zou daarmee in seconden uit te voeren zijn.

De eerste concrete Rowhammer-aanvallen werden in 2015 door Google geopenbaard. Hammering-aanvallen werken door geheugenlocaties aan een groot aantal lees- en schrijfacties te onderwerpen en zo aangrenzende bits van 0 naar 1 of omgekeerd te flippen. Sindsdien zijn veel meer Rowhammer-aanvallen bedacht, waaronder via JavaScript en op ecc-geheugen.

Ook de Spoiler-optimalisatie is toe te passen via JavaScript in sandboxomgevingen, schrijven de onderzoekers in hun onderzoeksdocument met als titel: Spoiler: Speculative Load Hazards Boost Rowhammer and Cache Attacks.

Update, vrijdag, 16.00: Volgens beveiligingsonderzoeker Herbert Bos van VUSec, het Systems & Network Security Group van de Vrije Universiteit Amsterdam, is het Spoiler-lek niet erg groot. "Het is redelijk interessant werk, verpakt in een wat ontoegankelijke paper, met beperkte impact." Volgens hem zijn er al meer technieken gevonden voor het vinden van aangrenzende delen van fysiek geheugen.

Zijn collega Kaveh Razavi valt hem bij. "Om een Rowhammer-aanval uit te kunnen voeren moet je eerst de fysieke adressen van je toegewezen geheugen vinden. Bij sommige van onze vorige aanvallen gebruikten we grote geheugenpagina's. Maar die zijn niet altijd beschikbaar, zoals bij mobiele telefoons. Bij onze GLitch-aanval van vorig jaar gebruikten we geïntegreerde gpu's om informatie over de adressen van fysiek geheugen te krijgen. Deze paper beschrijft een sidechannelaanval die vergelijkbare informatie op Intel-processors levert."

Reacties (25)

[lordawesome]

Beetje laat bericht over het Spoiler lek. Over laat gesproken, Intel is 90 dagen geleden hiervan op de hoogte gebracht. Dat ze nu nog geen fix hebben is slecht nieuws voor Intel bezitters of potentiële kopers. Of het is niet te fixen met software, of de fix heeft een flinke impact op performance.

[Verwijderd]

En aangezien het een uitbreiding van een nog niet gefixte eerdere loophole is, terwijl eerdere exploits ook al merendeel slachtoffers veroorzaakte onder Intel-architectuur, lijkt me dat server-beheerders steeds en steeds meer zullen zeggen 'We gaan sowieso voor Epyc' bij vervanging van de hardware.

Intel begint een aardig reputatie probleem te krijgen.

[Dennism]

Ik vraag me eigenlijk af hoe "nieuw" dit is, het lijkt mij als ik het zo bekijk een beetje op een verlengstuk van Rowhammer, ik vraag me dan ook af of mitigations voor Rowhammer dit niet ook verhelpen.

[Verwijderd]

Ik begrijp zelf niet waarom er maar 1 AMD cpu word getest en niet net als bij intel 10 versies dat het meest worden gebruikt.
Is dit gesponsord door AMD en ARM????

[Dennism]

Kans is groot dat dit gebeurde omdat Intel op markten zoals de desktop en de server / datacenter markt een enorm marktaandeel heeft en Qualcom / AMD daar vergeleken met Intel (nog) relatief klein zijn. Een exploit vinden die werkt op 90%+ van de machines heeft vaak meer zin dan een exploit vinden die slechts op een paar% van de machines werkt (tenzij het om zeer gespecialiseerde aanvallen gaat). Qualcom is echter op de mobile markt wel zeer groot, en zou daarom eigenlijk ook zeer goed getest moeten worden.

Verder is het ook logisch dat je verder door test zodra een type vatbaar blijkt te zijn.

Wel vind ik het vreemd dat ze van ARM en AMD 2 relatief oude modellen pakken, zeker het AMD model is volgens mij niet gangbaar meer. Daar zou je toch zeker verwachten dat ze op Zen gebaseerde Sku's zouden testen.

[Reactie gewijzigd door Dennism op 23 juli 2024 01:58]

[OfNoAvail]

Ik begrijp niets van wat hier staat... maar ik voel me toch veiliger!

[2green]

Heb je dan een rowhammer bestendige ram module?

[MrMonkE]

Urgh.. iets zegt me dat we ook hier weer performance slachtofferen.
Maar "Better safe than sorry".

[Gekke Jantje]

De performance verlies is ook alleen maar in hele specifieke gevallen merkbaar en te zien in sommige benchmarks met name op Linux. Genoeg benchmarks te vinden op het net.

Gelukkig worden eventuele performance verliezen ook weer teniet gedaan door windows updates, ik weet echter niet hoe dit zit met Linux.
https://nl.hardware.info/...tatiefix-voor-spectre-bug

[Sp3ci3s8472]

Dit is niet de Spectre bug waar nu een fix voor is. Dit is weer een nieuwe.

[2green]

Ik vermoed dat Gekke Jantje wel weet waar hij het over had, google maar eens op rowhammer, pmu, ram en performance. Vooral in de kernel list staan laaaange discussies over voorstellen die voorselecteren op betrouwbaarheid versus snelheid.

[Sp3ci3s8472]

Zijn aanname dat dit wel losloopt en er een fix voor komt zal best kunnen.
Als ik de discussie op Phoronix mag geloven (en dat doe ik eerder dan de redacteurs van Tweakers/Hardware.info) waar mensen met Intel en AMD systemen dit ook testen is het bij Intel momenteel eigenlijk altijd met zekerheid een rowhammer aanval uit te voeren en bij AMD dus niet.

Vandaar dat ik het statement van Intel een beetje zwak vind en het er niet automatisch mee eens ben dat dit wel met een patch wordt opgelost die ook het prestatieverlies mitigeert.
Voor huis tuin en keuken gebruikers zal er inderdaad weinig veranderen. Voor gevirtualiseerde servers is dit waarschijnlijk een groter probleem, voor zover ik het begrijp. Als jij bitjes kan omgooien in het geheugen en dit consistent kan doen dan kan je uiteindelijk bij de data van iemand anders.

[Reactie gewijzigd door Sp3ci3s8472 op 23 juli 2024 01:58]

[2green]

Je conclusie komt overeen met wat ik hoorde van een kernel ontwikkelaar die hier iets mee deed, mijn kennis op dit gebied is beperkt tot wat maillinglist discussies en een aantal papers die hierover geschreven zijn (wel interessant trouwens om op te zoeken). Merk wel dat iedereen meer intel gebruik, zelfs in de verschillende onderzoeken, waardoor je snel een vertekend beeld krijgt. Maar het afwijkingspercentage van de AMD testgevallen lag ook lager, dus denk dat het wel klopt dat amd er minder last van heeft.

Het prestatieverlies zal intel echt wel mitigeren omdat het anders hun reputatie kost, maar om dat te bereiken gaan ze ook de oplossing mitigeren . Met het stormvloed aan securityhacks sinds zo'n beetje 2014 zijn ze heel handig geworden in het verkopen van minder security voor meer performance.

[Gekke Jantje]

Iets zegt me dat we ook hier weer performance slachtofferen

Ik neem dus aan dat ik in ging op zijn uit spraak wat het verleden aan gaat.

Ik persoonlijk maak me er niet meer druk om als huis tuin en keuken PC gebruiker.

[The Zep Man]

Ik persoonlijk maak me er niet meer druk om als huis tuin en keuken PC gebruiker.

Dat is de juiste instelling.

Zelf heb ik nog een notebook met een 2e generatie i7 (Sandy Bridge). Daar is een microcode update voor uitgegeven door Intel. Deze heb ik geïntegreerd in Coreboot zodat deze geladen wordt voordat het besturingssysteem wordt gestart. Geen merkbaar snelheidsverschil te merken in dagelijks gebruik.

De prestatieverschillen zullen enkel kritiek zijn voor systemen waarbij een bepaalde piek behaald moet worden.

Van wat ik begrijp is het onwaarschijnlijk dat Intel Spoiler met een microcode update kan oplossen.

Rowhammer zou gemitigeerd kunnen worden met bepaalde geheugen banken/chips. Misschien wordt het tijd om wat kwaliteitseisen bij DDR bakkers te leggen, zeker met de huidige prijzen van het geheugen in het achterhoofd.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:58]

[2green]

uiteraard zit dit verlies op zowel windows als linux, meetbaar via pmu's en uiteraard hebben beiden sinds wat is het 2016? de nodige aanpassingen hierop.

Onderscheid maken tussen windows en linux op dit punt is niet te doen en zou je daarom ook niet moeten doen .

[Gekke Jantje]

Ik zie veel reviews maar het verlies was niet of nauwelijks te zien, zelf kleine winsten in bepaalde benchmarks. Ik ga me er dan ook maar niet druk om maken gezien het verlies niet zit in datgene wat ik met mijn PC doe.

[2green]

Het verlies is voor ontwikkelaars "aanzienlijk", aangezien die kijken naar codepaden in termen als verwerkingtijd, complexiteit, etc. Maar je hebt helemaal gelijk dat je je er niet druk om hoeft te maken. Tevens is de gekozen oplossing bij zowel windows als linux niet eens 100% waterdicht.

[ariekanari]

De retpoline patch maakt het opstarten een stuk sneller is mijn persoonlijke ervaring. Of programma's daadwerkelijk sneller starten kan ik niet objectief genoeg vaststellen.

N.B. De retpoline patch werkt niet op alle CPU's.

https://www.bleepingcompu...oline-spectre-mitigation/

[mutley69]

Het is in elk geval erg pijnlijk voor intel dat een low-end AMD niet kwetsbaar is - en al hun cpu's sedert core2 quasi allemaal in de hoofdprijs gevallen zijn. Blij dat ik wintel-outsider ben al enkele maanden nu!

[Verwijderd]

weer een hoop onzin wordt hier verteld wat kant nog wal slaat, alleen de post van 'arikanarie' gaat hier serieus op in, als men die gevolgt had en men had het echt alles eens goed doorgenomen dan had men kunnen lezen dat het om sommige DDR3 latjes gaat die niet goed samengesteld zijn welke door deze "Rowhammer" getroffen KUNNEN worden.

Wat even heel erg belangrijk is, is dat men WEET HEEFT van HOE hardware RAM werkt en HOE deze aangesloten zit in een geheugenbank als totaalplaatje en vooral alle signaalreeksen van hoe deze werken á functioneren ten opzichte van elkaar.
Als je dit niet weet, helaas, dan is dit allemaal geacadabra want dit is wel heel belangrijk als totaalplaatje gezien, want hier valt of staat mijn artikeltje weer want dit is nu eenmaal voor hardware techneuten eenmaal bedoeld.

Aangezien het een puur hardware probleem qua boot procedure betreft heeft Windows hier al actie op ondernomen dmv patches ondertussen, of andere Operating Systemen hier al actie op ondernemen heeft is mij onbekend aangezien ik alleen Windows systemen gebruik in basis.

De onderzoekers zijn inmiddels tot de conclusie gekomen dat OOK DDR4 geheugens besmettelijk zijn en zo ook de ECC geheugens qua zakelijke markt.

ziet voor dit totale onderzoek https://tweakers.net/nieu...vallen-met-rowhammer.html en voor het verslag van het totale onderzoek, overigens tijdelijk https://cs.vu.nl/~lcr220/...cploit-press-preprint.pdf

Op pagina 5, rechter kolom, is nu juist beschreven "ERROR injection with an shunt probe" en hier is van belang dat men weet heeft van HOE een ram werkt en vooral HOE deze aangesloten zit in een geheugenbank ten opzichte van elkaar. De berekeningen links daar van zijn daar onderhevig aan, beginnende op punt 4 op pagina 4, Theoretical Foundation, zijn daar onderhevig aan.

Voor hardware leken is dat denk ik wel moeilijk, voor hardware techneuten zoals ik is dat gewoon gesneden koek

Punt hierbij aangaande Intel is dat betreffende het cold-boot process en dat is de schuld van Intel zelf, dat de ECC-function niet gedocumenteerd is voor Intel-1 en dat die voor Intel-2 & Intel-3 processors onvoldoende tot zelfs verkeerd gedocumenteerd is.
Dit terwijl bij AMD dit volledig gedocumenteerd is en zodoende betreffende Intel te concluderen is dat veel Intel Prosessors totaal niet is na te gaan of men wel of niet is na te gaan of deze bevattelijk zijn voor Rowhammer, dit in tegenstelling voor AMD alleen AMD-1 hiervoor vatbaar is en verder niet (als ik het goed gelezen heb).

DAT is nu de kracht van alles goed documenteren, iets waar Intel nog een handje mee heeft om dit nogal eens na te laten als zijnde 'bedrijfsgeheim' terwijl de feitelijke waarheid is dat ze het kwijt zijn.


Dit is trouwens nog niet een definitief document, the definitieve versie wordt bekent tijdens de https://www.ieee-security.org/TC/SP2019/.

Zelf heb ik het ook nog niet helemaal doorgelezen, intressant om te lezen in iedergeval voor mij als hardware PC bilder.

De conclusies die hierui voortkomen zijn nogal duidelijk, inmiddels zijn er al een heleboel maatregelijk bekend gemaakt, deze zal ik later eventueel nog toevoegen van hoe/wat/waar.

Ronald

PS

Inzichtelijke film hierover >> https://www.youtube.com/watch?v=-JXZbGj0kFc, duurt 1 uur.
Project ZERO >> https://googleprojectzero...owhammer-bug-to-gain.html

PS2 - men kan op een bepaalde wijze aan Rowhammer blijkbaar ontkomen

Nu schijnt er goed nieuws te zijn om aan Rowhammer te kunnen ontkomen, door een "Natieve Client Sandboxing" te draaien, dit kan men hier vernemen >> https://developer.chrome....64-sandbox#x86-64-sandbox onder toevoeging van bepaalde opties aldaar beschreven.

Het mijne weet ik er nog niet van, moet ik uitspitten maar is een onderdeel van Project Zero ook weer

Bij Project Zere staat bv ook beschreven waarom ARM processors niet vatbaar zijn voor Rowhammer en wel omdat er geen unprivileged cache-flush instructions bestaan. (ARM Linux heeft een cacheflush() syscall, gebruikt door JITs, voor synchronising instruction en data caches. Voor x86, the i-cache en d-cache zijn synchronised geautomatiseerd, zo CLFLUSH is niet nodig voor deze ARM processoren.)
Zodoende hoef je ook geen enkele ARM processoren te gaan testen, het is totale tijdverspilling en alleen leken en onnozelaars alhier die totaal geen verstand van PC hardware hebben veronderstellen dit, zoals gewoonlijk staan "altijd de beste stuurlui aan de wal tijdens de storm", zoals hier.

ARM processor info >> http://infocenter.arm.com.../DDI0092B_ARM940T_TRM.pdf

De wijze waarop ARM cleaned/flushed zie hoofdstuk 4.4.5, daar staat beschreven hoe dit gebeurd, een totaal andere wijze dan Intel/Amd dit doet.
Trouwens, heel hoofdstuk 4 is van belang wil men dit goed kunnen begrijpen als totaalplaatje.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:58]

[Bazer]

is het niet te detecteren dat op bepaalde geheugenlocaties veelvuldig wordt gelezen/geschreven?
dan kun je toch een aanname doen dat er een rowhammeraanval gaande is?
of denk ik te makkelijk....

[MaestroMaus]

Er zijn genoeg normale situaties waar adressen veel gelezen en bewerkt worden. Denk bijvoorbeeld aan een for-loop die iedere loop een getal met één ophoogt en tijdens de loop dit getal gebruikt.

[Verwijderd]

This security shortcoming can be potentially exploited by malicious JavaScript within a web browser tab, or malware running on a system, or rogue logged-in users, to extract passwords, keys, and other data from memory. An attacker therefore requires some kind of foothold in your machine in order to pull this off

Iemand moet dus eerst al binnen zijn op je PC om dit te kunnen doen. (al dan wel niet via de browser).

Het lijkt mij (maar ik ben zeker geen specialist) dat er toch zeker wel een manier moet zijn om die te executen code (vooral in een browser) te detecteren.

Als dit gebeurt via een "traditioneel virus" / malware dan ligt er waarschijnlijk al veel meer data van je op straat.

[Marctraider]

Ach, zal altijd een balans zijn tussen performance vs beveiliging. Hoe complexer een chip hoe meer potentiele attack vectors. Idem ditto met software.

[Reactie gewijzigd door Marctraider op 23 juli 2024 01:58]