Onderzoekers vinden nieuwe cachekwetsbaarheid in AMD-processors

Onderzoekers hebben een sidechannel-kwetsbaarheid ontdekt in veel moderne processors van AMD. Het gaat om een zwakte in de L1D-cache. AMD brengt geen update uit en zegt dat het niet gaat om nieuwe kwetsbaarheden.

Het onderzoek komt van wetenschappers van de Oostenrijkse technische universiteit van Graz en de Franse universiteit van Rennes. Die noemen de kwetsbaarheid Take A Way. Het gaat om een zwakte in de L1D-cache. De onderzoekers beschrijven twee aanvallen in hun paper waarbij data uit die cache kan uitlekken. Ze hebben die aanvallen ook in de praktijk kunnen uitvoeren.

Het is niet de eerste aanval op processors die misbruik maakt van de cachefunctie. Een jaar geleden ontdekten onderzoekers van dezelfde universiteit van Graz een methode om Intel-cpu's af te luisteren met de zogenoemde Zombieload-aanval. Anders dan bij veel andere cachekwetsbaarheden in cpu's zeggen de onderzoekers dat zij de aanval van een afstand hebben kunnen uitvoeren. Dat gebeurde in een zelf opgezette omgeving waarbij de wetenschappers met JavaScript data lieten uitlekken met een snelheid van 588,9kB/s.

De wetenschappers hebben geen definitieve lijst met getroffen cpu's opgesteld. Ze zeggen dat ze het lek hebben weten uit te buiten op AMD-processors van 2011 tot en met 2019. De onderzoekers stapten in augustus vorig jaar naar het bedrijf voor openbaarmaking, maar AMD brengt geen update of mitigatie voor het probleem uit. Op een beveiligingspagina schrijft het bedrijf dat de twee kwetsbaarheden geen probleem vormen, omdat het 'niet gaat om nieuwe speculation-based-aanvallen'. Het bedrijf verwijst daarbij naar eerdere maatregelen die het heeft genomen om speculative execution-aanvallen te mitigeren. Ook zouden gebruikers andere beveiligingsmaatregelen moeten nemen, zoals het inschakelen van antivirus.

In de paper staat dat het onderzoek deels is gefinancierd door Intel. Het bedrijf financiert volgens een van de onderzoekers dergelijke papers wel vaker, ook als het gaat om kwetsbaarheden in Intels eigen cpu's.

Reacties (108)

[DarkJack]

Kleine sidenote, de professor van deze onderzoekers gaf ook volgende commentaar op de vraag of deze vulnerabilities even erg waren als Zombieload en Meltdown

"Certainly not. The attacks leak a few bit of meta-data. Meltdown and Zombieload leak tons of actual data."

https://mobile.twitter.com/gnyueh/status/1236178639483527168

[t_o_c]

+3

Ook weer erg matig van Tweakers (zoals wel vaker de laatste tijd) dat een artikel schijnbaar word gebaseerd op een ander artikel zonder dat er een beetje extra onderzoek word gedaan.

Nu lijkt het net alsof er een grote kwetsbaarheid is en AMD daar niks aan wil / kan doen terwijl de situatie in werkelijkheid dus vrij andere is.

[Scriptkid]

Paper is sponserd by intel, dan moet je het wel groot brengen natuurlijk.

[Plopeye]

In het stukje ACKNOWLEDGMENTS (pagina 11) staat inderdaad het volgende:

Additionalfunding was provided by generous gifts from Intel. Any opinions,findings, and conclusions or recommendations expressed in thispaper are those of the authors and do not necessarily reflect theviews of the funding parties.

En ja Intel heeft in deze de schijn tegen, of de conclusie/beschuldiging waar is is maar de vraag...

[skunkopaat]

"Any opinions,findings, and conclusions or recommendations expressed in thispaper are those of the authors and do not necessarily reflect theviews of the funding parties."

Ligt het aan mij, of maakt dat woord het open voor interpretatie? Niet per se, maar kan dus wel.

[Zeerob]

Inderdaad, hier staat dus eigenlijk dat het wel enigszins waarschijnlijk is dat de conclusies de mening van de funders weergeven, maar dat dat niet perse zo is.
Waarschijnlijk ongelukkig geformuleerd.

[Thekilldevilhil]

Nee het is exact andersom dan iedereen het hier lijkt te interpreteren. Er staat, wij als onderzoekers geven hier onze conclusies, wat de funders hier over en van vinden kan best anders zijn. Het kan zomaar ook zomaar hetzelfde zijn.

Het is om aan te geven dan wat de onderzoekers ook vinden, Intel mag een andere mening aangedaan zijn. Mensen lijken hier te lezen dat Intel zijn mening zou opdringen aan de onderzoekers, maar dat staat er niet.

Tussen de regels door lezen en er staat eigenlijk dat de funders niet is gevraagd of ze het eens zijn met de bevindingen. Wat natuurlijk ook hoort. Anders krijg je druk van de funding partners.

[Reactie gewijzigd door Thekilldevilhil op 24 juli 2024 06:24]

[boolean]

Fijn dat er nog Tweakers zijn die hun begrijpend lezen diploma wel hebben behaald

[mjl]

Kan me voorstellen dat intel het eens is (kan zijn) met de conclusie, de mening is echter niet door Intel opgelegd of beïnvloed (buiten dat er een mogelijkheid is dat zonder funding het onderzoek wellicht niet gedaan was).

[Mathi159]

Nee, het impliceert dat dit onderzoek onafhankelijk is van wat de financiers ervan vinden.

[Kevinp]

Hoeft niet, veel partijen (volgensm ij ook Intel) hebben geld over voor het vinden van kwetsbaarheden.

Als dat de brond van hun geld is (intel kwetsbaarheden) dan valt het wel mee.

Als Intel betaalt om AMD te "hacken" is het iets anders.

[Verwijderd]

Why not both?
Het is win-win voor beide partijen..

[dez11de]

Ze kunnen niet uitsluiten dat 2 partijen toevallig dezelfde mening hebben natuurlijk.

[QinX]

Klopt, als ik jou geld geef voor onderzoek en uit de onderzoek komt resultaat X en ik had zelf ook resultaat X verwacht, dan komen wij hetzelfde overeen, als jij resultaat X hebt en ik verwacht Y dan komt dat niet overeen.

[Scriptkid]

je leest mijn opmerking verkeerd,

het maakt niet uit wie de blame treft al wat het een intel processor , het feit dat je gesponsord wordt maakt het natuurlijk dat je het groot maakt om het geld binnen te blijven halen, niet om ze AMD zuur te maken.


Als jij kleine dingen vind die je groot in het nieuws kunt brengen zullen ze in de toekomst meer geven dan wanneer jij nooit iets nieuws waardig uit brengt.

[magician2000]

Niet te vergeten dat het toevallig gunstig uitkomt voor sponsor Intel dat er kwetsbaarheden gevonden zijn in de processoren van de concurrent. Op die manier zullen ze eerder geneigd zijn om betreffende onderzoekers nogmaals een "funding" te geven.

Ik denk dat je als onderzoeker wel heel sterk in je schoenen moet staan wil je hier niet op zijn minst enigszins rekening mee houden (oftewel gebruik van maken en het nieuws groter brengen dan het is).

Eén van de redenen dat ik onderzoeksresultaten waardeloos acht zonder inzage te (kunnen) hebben in het volledige onderzoek en de gehele scoop van het onderzoek.

[catfish]

Intel laat een onderzoeksteam het product van de concurrent onderzoeken.
Logisch, want ze winnen 2 keer:
- de onderzoekers proberen te doorgronden hoe de cpu werkt (wat intel uiteraard zeer interessant vindt)
- als ze bugs vinden is dat interessante PR

[robvanwijk]

of de conclusie/beschuldiging waar is is maar de vraag...

De onderzoekers zetten hun eigen naam erop. Als achteraf blijkt dat ze onzin praatten (hetzij opzettelijk, hetzij per ongeluk), dan is het hun eigen geloofwaardigheid (en carrière) die daaronder leidt. Nou kunnen we strikt genomen natuurlijk niet uitsluiten dat ze zich oprecht vergist hebben, maar dat is wel heel erg onwaarschijnlijk. Dus nee, dat Intel een financiële bijdrage heeft geleverd geeft mij in elk geval geen reden tot zorgen over de correctheid van dit onderzoek.

[xbeam]

Wanneer Google onderzoeksprogramma’s bug’s vind in OSX of Windows. Met door Google gefinancierd onderzoek geld is dat dan ook gelijk dubieus?

Het is het belang van alle bedrijven dat ook de bugs van de concurrentie gedicht worden. Bug’s en hackes van concurrenten zijn schadelijk voor de hele industrie en ze weten allemaal dat ze zelf ook een keer de lul zijn. dus beter help je elkaar in de industrie om als volwassen de boel veilig te houden en concurreer je op prijs en kwaliteit.

Marketing voeren op kwetsbaarheden en bug van concurrent is het zelfde als met boemerang kogels schieten ze komen zeker weten allemaal terug Allen weet je nooit Waneer en waarvandaan.

Dat er bug in de AMD CPU zijn gevonden door Intel is niet eens zo dubieus. AMD neemt een x86 licentie af bij Intel.

Daarom is het juist heel serieus te nemen dat Intel x86 gelicentieerde architecturen laat reviewen Als ze dit zouden doen om AMD in kwaad daglicht te zetten beschadigen ze ook zich zelf iedereen in branche doorziet zo iets gelijk met het risico op imago schaden en dat men x86 juist nog sneller de rug toe gaat keren

Voor Intel is het juist belangrijk en in het voordeel van Intel dat AMD hoogwaardige kwaliteit levert. Reputatie schade van de x86 architectuur is het laatste wat Intel kan gebruiken. Daarnaast zorgt meer concurrentie binnen een een architectuur voor een gezonder speelveld wat innovatie bevordert en daar is Intel (X86) aan de verliezend had.

Ik denk dat ze zich zelf nog steeds met hun hoofden tegen de muur slaan vanwege de beslissing om ARM Holdings geen x86 licentie te geven. Je ziet hoe snel een architectuur kan ontwikkeling als er meerdere bedrijven concurrenten op basis van de zelfde architectuur.

[Reactie gewijzigd door xbeam op 24 juli 2024 06:24]

[magician2000]

Wanneer Google onderzoeksprogramma’s bug’s vind in OSX of Windows. Met door Google gefinancierd onderzoek geld is dat dan ook gelijk dubieus?

Zeker weten dat het dan gelijk dubieus is. Google heeft andere belangen daarbij. Ze zijn echt niet enkel uit op het verbeteren van de wereld van de softwarecode.

Ga er maar gerust vanuit dat wanneer ze kwetsbaarheden vinden bij hunzelf het eerst opgelost zal worden alvorens het te melden (afhankelijk van ernst kwetsbaarheid). In alle gevallen zullen ze overwegen wat voor Google als bedrijf het beste is om te doen.

[xbeam]

Ow volgens mij vindt techbedrijven heel vaak kwetsbaarheden bij hun Concurrenten en helpen ze elkaar met oplossen daar van.


nieuws: Kwetsbaarheden in iOS werden jarenlang gebruikt om iPhones te bespion...


https://www.security.nl/posting/618169#posting618268

[Remenic]

Psst, macOS het heeft sinds 2016 een andere naam. En gelukkig maar, want men wist die X niet eens fatsoenlijk uit te spreken.

[xbeam]

Psst, Gelukkig weet nu iedere IT professional door het gebruik van MacOS of OS10.15 gelijk wanneer hij met een gebruiker te maken heeft.

[mae-t.net]

Ik ben geen gebruiker, maar ik kan je garanderen dat ik niet zonder nadenken 'de enige juiste naam' gebruik. MS Windows heeft door de jaren heen ook niet altijd hetzelfde geheten. Vooral op telefoons was het een beetje onoverzichtelijk. Ik denk dat je indruk van "iedere IT professional" niet helemaal klopt.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 06:24]

[xbeam]

Precies daarom nummert ook MS hun OS heel logisch door met NT versie nummers en gebruiken ze voor brede publiek de marketing namen zoals Windows xp of windows 7, Vista en Windows 10 Die weer zijn ingedeeld In verschillende edities.

[TheVivaldi]

Nee, het is O.A. gefinancierd door Intel. Lees de paper maar: er staan ook andere financierders genoemd.

[j1b2c3]

Maar intel wordt wel specifiek appart bedankt voor de gulle bijdrage

[Zyppora]

Intel kan natuurlijk extra geld tegen zo'n onderzoek aangooien in de hoop dat er iets ernstigs gevonden wordt waarmee ze de aandacht van hun eigen lekke cpus af kunnen halen. Daarmee beïnvloeden ze dat onderzoek nog niet per se. Zeker gezien de uitspraak die @DarkJack hierboven quote krijg ik niet het idee dat er veel bias op dat onderzoek zit, ondanks waar het geld vandaan komt.

[TheVivaldi]

Nee hoor, helemaal niet apart: er is een opsomming gemaakt van alle financierders en Intel staat daar gewoon tussen. De woordkeuze in het bedankje is ietsje anders, maar verder worden ze niet meer benadrukt dan de rest op de lijst.

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 06:24]

[theduke1989]

Tja je wilt het nieuws toch als eerste hebben als nieuwssite. Dus de research kunnen ze achteraf doen.
Vaak wordt het dus alsnog achteraf toegevoegd.

Maar ik begrijp je punt volkomen.

[jacket13]

Heel erg off topic maar nee.

Ik kom naar tweakers omdat het nieuws juist verrijkt is met meer feiten en achtergrond informatie wanneer dat ook van toepassing is.

Dus in dit artikel mis ik inderdaad de significantie van deze kwetsbaarheid en waarom AMD het nou precies niet zo relevant vindt.

Ik kan ook begrijpen dat veel van deze attacks niet zo erg zijn voor mensen die de computer recreatief gebruiken, enigste wat ze dan buit maken zijn de textures van je game of de sound samples die zijn ingeladen in je geheugen.

Kan Intel en AMD niet beter goed gebruik maken van snellere technologie en er een security rating bij geven? "Fast CPU but only 5/10 secure" of "Intel 10600 has a rating of 6" Ik ben wel van mening dat de meeste aanvallen zo niet relevant zijn voor een hele groep gebruikers....

[Fijinees]

Zo n nieuw was nieuws niet hoor. Het was 2 dagen geleden al op ZDnet, met een stuk meer info.

[kimborntobewild]

'A few bit' komt niet overeen met 588.9kB/s.

[stuiterveer]

Die 588.9KB/s komt dan ook niet overeen met deze nieuwe kwetsbaarheid, maar met Zombieload.

[kimborntobewild]

Ah, dank. Heb het niet goed gelezen.

[sympa]

Edit: de 588.9KB/sec is voor 2 processen die bewust met elkaar communiceren.
Enfin, met deze kwetsbaarheid kan het geheugenaccesspatroon van een ander proces bepaald worden, door timing te meten. Dat kan van nature met een cache (als ik A lees, en jij dan kijkt hoe snel je A kan lezen, weet je dat iemand naar A heeft gekeken als het snel gaat) en daar worden caches tegen beveiligd.
Het misbruik van de way predictor omzeilt deze beveiligingen dan weer...

[Reactie gewijzigd door sympa op 24 juli 2024 06:24]

[SubSpace]

Zo lees ik het niet in het bovenstaande artikel; er wordt even een zin aan Zombieload gewijd, en meteen weer terug naar de nieuwe kwetsbaarheid. Wellicht slechte vertaling?

[MeanGreen]

Hoeft niet natuurlijk. Ik kan een afstand van 10 centimeter ook uitdrukken in kilometer per uur

[Verwijderd]

Uhhhh nee.

[xbeam]

Uhm wel dat is namelijk precies wat we doen met lichtjaar.

Dat is een afstand definiëren op basis van snelheid/kmh

Op minder Minder wetenschappelijke basis doe je dit waarschijnlijk elke dag. Als reist met het openbaarvervoer Communiceer je waarschijnlijk in aantal minuten dat je onderweg bent. Terwijl je auto voor zelfde afstand zegt nog een x aantal km. Op beide momenten ga je er vanuit dat iemand weet wanneer aankomt. Dit gebeurt op basis van vaste waarde van het transport middel en wanneer 1 van de waarde binnen de driehoek bekent is kan je afstand Willekeurig uitdrukking in de overbleven waarde afhankelijk welke variable je aangereikt krijgt.

Reken technische is dit de zelfde driehoek eenheid. watt,volt,ampere en gebruik je de verschillende eenheidswaarde afhankelijk van de situatie.

[Reactie gewijzigd door xbeam op 24 juli 2024 06:24]

[Nox]

Laat eens zien dan hoe je enkel de afstand in enkel een snelheid kan weergeven.

[xbeam]

Goed lezen dat zegt hij niet hij zegt een afstand van 10 cm uitdrukken in km/h

Maar speciaal voor jouw de afstand naar de planeet mars is 0,000042105 LJ Of gelijk aan 3.983441e+8km/h

[Reactie gewijzigd door xbeam op 24 juli 2024 06:24]

[Nox]

Hoeveel km/h is 10cm dan?

[xbeam]

succes

[Reactie gewijzigd door xbeam op 24 juli 2024 06:24]

[Nox]

398344100 km/h is 10cm? Hoeveel tijd moet ik dan gebruiken? Als ik er volledig naast zit ben ik wel benieuwd naar een bron.

Een lichtjaar is de afstand die licht in een jaar aflegt. Dat omvat al een tijdseenheid. Als je een snelheid geeft moet je om tot een afstand te komen ook een tijd meegeven. 100km kan je dan ook uitdrukken in 10 km/h mits je erbij vermeldt dat het om 10 uur gaat. In die driehoek heb je gewoon twee van de drie variabelen nodig om de derde te berekenen.

[Reactie gewijzigd door Nox op 24 juli 2024 06:24]

[xbeam]

Ik ben ook geen rekenwonder maar als ik naar je antwoord kijk gaat het mis omdat je niet helemaal begrijpt waar km/h Voor staat.

En daarom niet helemaal ziet dat LJ en kmh de zelfde rekenen som is alleen op een andere schaal.
L= Afstand
J= 1 Jaar
Km= Afstand
H= 1uur
De Rekensom
Hij geeft de afstand namelijk 10cm en hij geeft een tijdsduur namelijk 1uur
En @MeanGreen vraagt dan het aantal km/h

[Reactie gewijzigd door xbeam op 24 juli 2024 06:24]

[Nox]

Die tijdseenheid van een uur zie ik niet terug in zijn post, ik denk dat het daar mis gaat maar 10cm per uur is natuurlijk easy om weer te geven in km/u, dat is peanuts

[xbeam]

Km/h = 1 uur
Snelheid is bevat altijd een vaste tijd.

Maar het goed om te horen dat niet altijd noodzakelijk is om eenheden te begrijpen om ze te kunnen toepassen

[Reactie gewijzigd door xbeam op 24 juli 2024 06:24]

[Nox]

Kilometer per uur, niet kilometeruur. Klein verschil, grote impact. Maar ik zal er rekening mee houden dat ik 48km/h van mijn werk woon en dat voortaan opschrijf in de ritregistratie

[xbeam]

.

[Reactie gewijzigd door xbeam op 24 juli 2024 06:24]

[kimborntobewild]

Km/h = 1 uur

Ik begrijp je redenering niet. km/h is niet hetzelfde als 1 uur. Zo is kW ook niet hetzelfde als 1 W. En is

Snelheid is bevat altijd een vaste tijd.

Snelheid bevat óók altijd een factor afstand. Een snelheid van bijv. '1 uur' bestaat niet. Je moet óók opgeven hoeveel afstand er in die 1 uur wordt afgelegd. En de tijd waarin een bepaalde afstand wordt afgelegd, is niet vast: want je kan zeggen: 36 km/h. Maar je kan ook zeggen: 10 m/s. De ene keer wordt de tijdseenheid uur gebruikt; de andere keer de tijdseenheid seconde. Dus... snelheid bevat niet altijd een 'vaste' tijd . Of ik begrijp je verkeerd.

[Reactie gewijzigd door kimborntobewild op 24 juli 2024 06:24]

[xbeam]

Natuurlijk wel het is 1kilo watt uur Als een apparaat een verbruik van 5 watt aangeeft is dan staat verbruik ook voor tijds periode van 1 uur.

Als een een planeet 0,5 lichtjaar bij ons vandaan staat dan geven we de afstand toch ook weer een met snelheid die nodig is om tot die afstand in jaar te komen.

[Reactie gewijzigd door xbeam op 24 juli 2024 06:24]

[kimborntobewild]

Als een een planeet 0,5 lichtjaar bij ons vandaan staat dan geven we de afstand toch ook weer een met snelheid die nodig is om tot die afstand in jaar te komen.

Nee, je kan afstand niet in snelheid weergeven.
Als een planeet 0,5 lichtjaar van ons vandaan is, dan is dat x kilometer. Maar het is niet x uur; dat zou slaan als een tang op een varken.

[dez11de]

Doe eens.

[Xm0ur3r]

Kleine sidenote? Ik vind dit een spotlight waard, dit is nogal een wereld van een verschil!
Ik snap dan ook wel dat AMD hier niet een update voor gaat uitbrengen wat weer perfomance omlaag brengt.

[CH4OS]

Ik snap dan ook wel dat AMD hier niet een update voor gaat uitbrengen wat weer perfomance omlaag brengt.

Ik denk dat je het dan anders leest; er komt geen nieuwe / extra patch voor. Wellicht wordt dit lek dus al gepatched met een andere update.

[skunkopaat]

"Op schrijft het bedrijf dat de twee kwetsbaarheden geen probleem vormen, omdat het 'niet gaat om nieuwe speculation-based-aanvallen'. Het bedrijf verwijst daarbij naar eerdere maatregelen die het heeft genomen om speculative execution-aanvallen te mitigeren."

Dat is dus mogelijk al gebeurd

[CH4OS]

Inderdaad, dat is precies wat ik zeg; dat er niets gedaan hoeft te worden, omdat dat al gedaan is.

[Reactie gewijzigd door CH4OS op 24 juli 2024 06:24]

[computerjunky]

Dan zou ik zeggen dat het al gepatched is niet dat je het niet gaat patchen.
Beetje vreemde statement zo. Net als zeggen ik ga niet werken als je je werk al gedaan heb.

[CH4OS]

Maar dat is ook precies wat ze zeggen, alleen wat anders opgevat wordt.

[TMoose]

+4

Deze informatie zou in een neutraal nieuwsbericht niet mogen ontbreken.

Dit maakt van het nieuwbericht een tendentieus stukje.

[-The_Mask-]

@TijsZonderH Lijkt mij toch wel essentiële informatie die nu mist in het artikel.

[Bozebeer38]

Ook voor de wat serieuzere vulnerability problemen zoals bij intel, is er redelijk wat nodig om er misbruik van te kunnen maken.

Het is een hoop gedoe om niets en vooral van belang als je een server draait met brakke security en pas laat software update etc.

Voor de gemiddelde consument is misbruik ervan praktisch nihil.

[kimborntobewild]

Servers zijn sowieso heel vaak niet gepatched naar de nieuwste updates.

[klakkie.57th]

hmmm hangt er maar vanaf hoe je het bekijkt.
Iedereen van ons neemt wel een cloud-dienst af, bedrijven of het gerechtsapparaat van een vreemd land kunnen op deze manier toegang krijgen tot "jouw" gegevens.

[Bozebeer38]

Dat hebben ze al.

Die nemen geen moeite een cloud server te hacken, die kijken gewoon mee met wat je doet.

Sleepwet etc.

[Verwijderd]

Ja maar met 90% marktaandeel is de kans wel aanzienlijk dat bij een eventuele aanval Intel CPU's getroffen zullen worden.

[kaas-schaaf]

Al deze cache en speculative execution attacks zijn voornamelijk van toepassing op virtualizatieproviders (lees: cloud). Laat daar nu net alle klantengegevens van veel bedrijven op draaien/zich bevinden. Daar is het namelijk wel makkelijk om toegang tot een machine te krijgen waar iemand anders zijn software op draait naast die van jou, waarna je via deze exploits data kan opvragen uit andere processen en memory regions dan die van jouw processen. Voor de klassieke thuisgebruiker zet het inderdaad weinig zoden aan de dijk, hoewel lekken via javascript ook aangetoond zijn maar niet heel praktisch op grote schaal. Gerichte aanvalleen wel, maar dat is een ander aanvalsprofiel dat voor het meerendeel van de mensen niet van toepassing is.

Overigens heeft deze exploit geen praktische zin zonder een andere, reeds gepatche, aanval zoals een van de spectre vulnerbilities.

[Cybermage]

tja of je nu intel of amd gebruik lek zijn ze allemaal. Kwestie van tijd dat ze ook bij amd wat vinden.

[Anonymoussaurus]

Lekker kort door de bocht. De één heeft meer (tot zover bekende) lekken dan de ander.

[Jerie]

Het gaat niet alleen om aantal; ook de impact is van belang. Deze kwetsbaarheid heeft minder impact dan Zombieload, zoals elders in dit draadje besproken.

[computerjunky]

Veel van de intel lekken hebben toegang tot mijn pc nodig. Newsflash: met die toegang kan je gewoon alles kopieren of remote viewing software of wat dan ook inslalleren. Die leak is dus irrelevant.
Voor een ander deel moet je de bios aanpassen. Daarvoor moet je dus ook al toegang tot de pc hebben.

Alleen de remote leaks zijn boeiend.

[batjes]

Meltdown en Spectre waren in eerste instantie ook via Javascript te exploiten. Die zijn door de browsermakers opgelost, niet Intel.

[Verwijderd]

Nee, dat is dus niet zo.

Weet niet of je sarcastisch probeert te doen maar Intel is toch wel echt veel kwetsbaarder dan AMD.

Dit zogenaamde kwetsbaarheid stelt ook niet zoveel voor.

[TheVivaldi]

Weet niet of je sarcastisch probeert te doen maar Intel is toch wel echt veel kwetsbaarder dan AMD.

Alleen omdat Intel met hun marktaandeel veel meer onder de loep ligt. Als er meer onderzoek wordt gedaan naar AMD, dan kan het er wellicht (let op: lees dus het woordje WELLICHT) heel anders gaan uitzien voor AMD.

[Verwijderd]

Dat is dus een aanname.

Tot nu toe is AMD veilig gebleken.

Bovendien valt alles nu op zijn plek omdat de afgelopen jaren Intel altijd de snelste CPU had terwijl AMD engineers echt niet incapabel waren of zo.

Nu blijkt dus dat Intel ten koste van de veiligheid de CPU's sneller konden maken.

Om nu dan te stellen dat AMD ook wel onveilig zou kunnen zijn is nergens op gebaseerd omdat het een pure aanname is. Al zouden er morgen ook AMD exploits bekend gemaakt worden is dat vandaag niet het geval.

[TheVivaldi]

Aanname? Ik heb bewust gekozen voor het woordje 'wellicht' en dat ook nog benadrukt, maar daar heb je blijkbaar alsnog overheen gelezen. Ik gebruikte expres 'wellicht' omdat het dus twee kanten op kan. Wellicht komt er meer boven water, wellicht ook niet. Ik zeg alleen dat we het niet bij voorbaat moeten uitsluiten.

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 06:24]

[Verwijderd]

Ja wellicht kan er zoveel. Voorlopig blijkt daar helemaal geen sprake van te zijn.

Wellicht kan mijn tante ook mijn oom zijn maar zolang ze dat niet is is dat niet zo.

[robvanwijk]

Om nu dan te stellen dat AMD ook wel onveilig zou kunnen zijn is nergens op gebaseerd omdat het een pure aanname is. Al zouden er morgen ook AMD exploits bekend gemaakt worden is dat vandaag niet het geval.

Ehm, misschien heb ik iets verkeerd begrepen, maar het klinkt alsof er vandaag een AMD exploit bekend is geworden...!? Dat haalt "nergens op gebaseerd" en "pure aanname" behoorlijk onderuit.

Ja okee, Intel heeft meer verschillende lekken. Maar als deze onderzoekers gelijk hebben en AMD cpu's zijn kwetsbaar via JS (dus remote; je hoeft iemand alleen naar je website te lokken, dat is een veel lagere drempel dan lokaal software moeten installeren), dan heeft het weinig zin om te bekvechten over "Intel is lekker dan AMD", dan is de conclusie "Intel en AMD zijn allebei lek" veel realistischer.

[Yezpahr]

Jouw post heeft bijna een therapeutische werking op mij. Eindelijk een geluid van rust en bescheidenheid.

Er zit wel een donkere kant aan dit onderzoek, ik bedoel alleen dat het een kwetsbaarheid heeft gecreëerd, niet alleen ontdekt maar ook gepubliceerd.
Op het eind van de rit zal dit natuurlijk alleen maar goed zijn want dan moeten ze het wel oplossen, maar gelukkig zijn in de meeste gevallen deze "kwetsbaarheden", vooral in dit specifieke AMD-geval, niet direct te misbruiken.
Zelfs de aanval mogelijkheden zijn al moeilijk te begrijpen omdat er met termen wordt geslingerd die specifiek voor dit onderzoek zijn uitgevonden.

Veel ongedocumenteerde zaken zijn (zoals het woordje ongedocumenteerd al weergeeft) niet te onderzoeken. Je moet zóveel voor-onderzoek, voor-kennis, ervaring en motieven al klaar hebben liggen dat "een aanval" moeilijk te doen is.

Nu het gedocumenteerd is wordt het pas gevaarlijk. En dat is vaak moeilijk te accepteren.

Als je er genoeg geld tegenaan gooit dan is *alles* onveilig gebleken.
Als je er genoeg reverse-engineering tegenaan gooit dan is *alles* te cracken.


-note:
Wat me opvalt is dat menig belangrijke details toch niet in dit artikel vermeld staan.

Bijvoorbeeld, even een paar quotejes uit het bron materiaal (van de paper zelf, niet dit artikel):
Er was reverse-engineering voor nodig, iets wat niet goedkoop in de schappen ligt of bij een fabriek even te drukken valt. Window of opportunity van bijna nul.

We reverse-engineered AMD’s L1D cache way predictor in microarchitectures from 2011 to 2019, resulting in two new attacktechniques.

Ze gebruiken exact dezelfde method-of-entry als bij de Spectre-attack.

We demonstrate a covert channel with up to 588.9 kB/s, which we also use in a Spectre attack to exfiltrate secret data from the kernel.

Note2:
Hè verdorie t.net waarom nou het handige quote-knopje uit de quick-use bar halen?

[Reactie gewijzigd door Yezpahr op 24 juli 2024 06:24]

[Verwijderd]

Euhh nee, totaal niet dus.

Je zegt in feite dat allebei de lekken even ernstig zijn terwijl de lek van Intel veel ernstiger en in grotere hoeveelheden aanwezig is.

Daarnaast heeft Intel of ze dat nu leuk vinden of niet een veel grotere verantwoordelijkheid omdat ze een veel grotere marktaandeel hebben.

Wat jij zegt komt neer op "een dief die een brood steelt is net zo erg als een gewapende bankovervaller"

[robvanwijk]

Wat jij zegt komt neer op "een dief die een brood steelt is net zo erg als een gewapende bankovervaller"

Nee, daar zit een wezenlijk verschil tussen. Ik zat meer te denken aan "een bankovervaller met een mitrailleur is net zo erg als een bankovervaller met een bazooka". Het is niet precies hetzelfde, maar het is allebei dusdanig ernstig, dat het mijns inziens geen nut heeft om te kiezen welk van de twee net even erger is.

[Niosus]

Valt nog te zien. De focus ligt inderdaad meer op Intel, maar dat betekent niet dat AMD even kwetsbaar is. De komende jaren zal dit wel duidelijker worden, maar op dit moment is het gewoon zo dat er minder kwetsbaarheden bekend zijn voor AMD CPUs.

Anderzijds heeft AMD ook echt wel een aantal features die het veel moeilijker maken om deze hardware bugs te misbruiken, zeker in cloud situaties. 1 van de grootste problemen met deze kwetsbaarheden is dat een virtuele machine data van een andere virtuele machine zou kunnen vast krijgen. Je zou dus in principe op Amazon AWS een hoop EC2 instances kunnen huren en dan gewoon gaan harvesten bij de buren. AMD heeft hier hardware accelerated memory encryption om ervoor te zorgen dat zelfs als er wat data lekt, het nog altijd encrypted is en dus (bijna) volledig waardeloos is. Dan moet je al een data lek kunnen vinden, en de encryption key voor die data vast krijgen. Dat lijkt me toch al een hogere drempel.

Intel gaat binnenkort ook met die feature afkomen, maar op dit moment is dat uniek voor AMD. Het lijkt er dus wel op dat ze goed hebben nagedacht over security bij AMD. We kunnen enkel afwachten wat de resultaten hiervan zijn op lange termijn.

[mae-t.net]

Zou intel zelf ook niet zoeken naar AMD-lekken?

Edit: kennelijk inderdaad meebetaald aan dit onderzoek. Als de concurrent de fouten in jouw product niet eens kan vinden, zal het product nog best redelijk zijn.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 06:24]

[batjes]

Niet de eerste keer ook. Ik meen me te herinneren dat rond meltdown/spectre Intel nogal wat moeite aan het stoppen was in het in de schijnwerpers zetten van AMD kwetsbaarheden en hier ook de knip voor getrokken heeft.

AMD ontkomt er echt niet aan door gebrek aan markt grootte. Meer dat AMD geen twijfelachtige keuzes neemt om een voorsprong te krijgen op de concurrentie. Intel heeft willens en wetens bepaalde design keuzes gemaakt om een voorsprong te krijgen op AMD. Want met terugwerkende kracht was Bulldozer zo slecht nog niet gezien AMD geen 50% achterstand had en Intel ondertussen een tiental procent punten ingeleverd heeft op de performance.

[Verwijderd]

Niet alleen dat maar bulldozer presteert ook beter met moderne besturingssystemen en naarnate meer multithreading word gebruikt.

[RoestVrijStaal]

Allemaal aan de VIA dan maar

[t link]

het is een kwestie van tijd maar dit is niks nieuws. je kan ook niet speculeren op die manier alsof de twee even kwetsbaar zijn. je kan alleen speculeren over de zekerheid waarmee we zeggen dat intel processors meer kwetsbaarheden hebben dan AMD processors.

[MartineEekhof]

Ook niet onbelangrijk: ze hebben alleen metadata kunnen onderscheppen als ik Tomshardware er even bij pak.

[Mopperman]

Heb je linkje?

[paulbenard]

https://www.tomshardware....-impacts-zen-architecture

[Dark Angel 58]

Is er helemaal geen manier om zulke lekken vanuit processor tegen te houden?

Misschien firmware in de processors in te bouwen? Zodat AMD geen nieuwe processors met fixs hoeven produceren, lijkt me wel een flinke materiaal besparing.

[ManDeJan]

Daarvoor is Microcode, sommige lekken kan je inderdaat patchen door die te updaten maar soms zijn er ook echt hardwarematige fixes nodig.

[Dark Angel 58]

Daarvoor is Microcode, sommige lekken kan je inderdaat patchen door die te updaten maar soms zijn er ook echt hardwarematige fixes nodig.

Hardwarematigie fixes nodig? Verdorie... hopelijk kunnen de processors zichzelf in de toekomst met nanoprobes repareren (zoals Borg technology uit Star Trek series). Dat lijkt me wel handig en fijn.

(oeps, hebben we Borgs gecreëerd??? )

[Tuinsteen]

Het is wat genuanceerder, maar AMD heeft wel vaker 'bugs' geplet door her uitgaves; https://tweakers.net/revi...-wat-is-het-probleem.html.

[Verwijderd]

CPU's zijn nou ook niet echt gigantische componenten.

Harddisks of monitors bestaan wat dat betreft wel uit meer materiaal.

[Pinkys Brain]

Een cache eviction type aanval is niet zo heel erg interessant. Gooi het op de hoop.

Het "mooie" van de prediction aanvallen is dat ze data lekken, niet alleen maar het feit dat een adres gelezen of geschreven werd. Daarom waren er patches voor nodig.

[Verwijderd]

Het was natuurlijk wachten hier op. Geen enkele CPU-architectuur is gegarandeerd honderd procent veilig, het enige wat uitmaakt is hoe CPU-bakkers hier mee omgaan en hoe toereikend ze richting de klanten zijn.

[t link]

Het onderzoek is zeker zinnig. ook onderzoek dat niet direct toepasbaar is, is erg nuttig. einsteins relativiteits theorie was ook niet meteen toepasbaar, het zorgde als fundament voor andere doorbraken. nu is dit niet einsteins relativiteits theorie maar die hyperbool gebruik ik om even duidelijk te maken dat onderzoeken bouwen op andere onderzoeken en dit dus indirect bijdraagt aan vooruitgang op andere gebieden. Als er uit een onderzoek komt dat iets geen effect heeft is bijvoorbeeld ook heel belangrijk, mensen vinden het alleen minder spannend. dat is een grote kwetsbaarheid in wetenschap.

[Reactie gewijzigd door t link op 24 juli 2024 06:24]

[markg85]

Wat een onzin vergelijking.
Ik ben helemaal voor wetenschap en onderzoek. Maar die zogenaamde cpu lekken ben ik wel wat klaar mee.

[t link]

het is totaal niet ongedacht dat je meerdere kwetsbaarheden combineerd om een systeem te pwnen, sterker nog dat gebeurt zo in de praktijk omdat het makkelijker is dan een non user interaction root access network accessable whatever exploit.

[Reactie gewijzigd door t link op 24 juli 2024 06:24]

[keur0000]

En dan is intel ook nog eens mede sponsor van het onderzoek geweest (al is het veel minder shady als bij die vorige breed gepubliseerde onderzoeken.): intel is sinds 2 jaar mede sponsor van de afdeling op universiteit die met dit onderzoek kwam. (wat wel precies begin op het moment dat de eerste speculative execution exploits bij intel publiek bekend werd)

https://nl.hardware.info/...-met-2019-ontdekt--update

[batteries4ever]

Dat klinkt eerst maar even ernstig, maar het is wel zo dat die greop ook Intel en ARM kwetsbaarheden ontdekt heeft; van door Intel gesponserde groep om AMD zwart te maken is dan denkelijk ook geen sprake, al ontstaat zo'n verdenking al snel... in deze fake-news wereld.

[mutley69]

Het lek is van een heel wat lagere grootte-orde dan het lek in de security-processor in de intel cpu's. Daar zou Intel eigenlijk al die processoren moeten inruilen. Halt - wat doe je met cpu's op 't mainboard gesoldeerd (een uitvindsel van Apple!). Dat wordt een dure grap dan - en dus gaat men wat met microcode gaan knoeien...

[computerjunky]

Inruilen serieus? Voor kwetsbaarheden die pf gepatched worden in browsers of een bios of zelfs alleen te exploiten zijn al de pc al aan voor je neus staat.
Onzin. En zelfs al zou intel willen kunnen ze echt 4 miljard processoren omruilen? Nee dan kan niet. Niet dat het nodig is.
Ik heb een 9900k gekocht terwijl ik wist dat deze 'leaks' er in zaten maar ik wist ook dat ze niks voorstelde.