Onderzoekers vinden lek in Intel-processors met HyperThreading

Onderzoekers van een Finse en een Cubaanse universiteit hebben een nieuwe side channel-aanval gedemonstreerd die werkt op Intel-processors met HyperThreading. Ze verwachten dat PortSmash, zoals de aanval is genoemd, ook werkt op AMD-processors.

De onderzoekers van de Tampere University of Technology in Finland en de Universidad Tecnologica de la Habana Cujae in Cuba hebben de werking van PortSmash geverifieerd op Intels Skylake- en Kaby Lake-processors. De aanval gebruikt de technologie van processors met Simultaneous Multithreading, of SMT. Daarom verwachten de onderzoekers dat ook AMD-processors die dit ondersteunen, kwetsbaar zijn.

De aanval berust op het laten uitlekken van data door de execution engine sharing voor SMT en werkt volgens ZDNet globaal door kwaadaardige threads naast legitieme threads te draaien, om zo achter gevoelige gegevens zoals cryptografische sleutels te komen. De aanval lijkt daarmee op een oude kwetsbaarheid die al in 2005 werd aangetroffen. Anders dan die techniek heeft PortSmash echter niets te maken met subsystemen van het geheugen of caching. De fixes voor de aanval uit 2005 werken dan ook niet, aldus de onderzoekers.

Ze hebben een proof-of-concept op GitHub gezet en Intel Security op 1 oktober ingelicht over hun bevindingen. Intel heeft op 1 november een patch vrijgegeven. Volgens een van de onderzoekers was het doel van het onderzoek om een einde te maken aan het gebruik van SMT, omdat dit inherent onveiligheid met zich mee zou brengen. OpenBSD schakelt daarom HyperThreading uit bij komende versies van het besturingssysteem.

Reacties (67)

[aex351]

Dit nieuwsartikel is wellicht niet volledig, of althans het leest nogal suggestief. Lees ook: https://www.theregister.c...sh_intel_security_attack/ voor een duidelijkere berichtgeving.

De onderzoekers (waarschijnlijke studenten) hebben een proof of concept uitgevoerd en ontdekt dat threads met Hyper Threading in combinatie met een Intel CPU's (Intel x64 processors) misbruikt kan worden om gevoelige informatie te decoderen. De broncode waarmee dit gereproduceerd kan worden hebben ze online gezet. Verder geven ze ook aan dat dit wellicht van toepassing is op andere processoren met een vergelijkbare architectuur.

Verder is de opmerking van Intel: dit is by design en dat het probleem softwarematig opgelost kan worden. AMD gaat onderzoeken in hoeverre deze ontdekking impact heeft op hun CPU's.

https://seclists.org/oss-sec/2018/q4/126
Severity: Low

[Squee]

Precies dit. Eigenlijk was dit onderzoek bijna van het niveau "water blijkt nat te zijn", als je het mij vraagt. Als je een processor hebt met SMT (wat Intel Hyperthreading noemt), dan is het inherent aan het design dat je delen van je processor pipeline dynamisch deelt. Dat daar meetbare verschillen in executies optreden waardoor je het gedrag van de applicatie die op een andere hardware thread op dezelfde core loopt is dus redelijk voor de hand liggend (en ook een van de redenen dat OpenBSD het uitschakelde).

Wat het onderzoek hier bijdraagt is dat ze laten zien dat een speciefieke OpenSSL versie informatie over het cypher kan lekken omdat er verschillende data afhankelijke executie paden zijn. Volgens mij is dat een redelijk goed begrepen probleem in de crypto/security wereld, omdat dit in veel gevallen ook zonder SMT zou kunnen door bijvoorbeeld op slimme manieren de instructie cache van een core te beinvloeden en meten. (een snel gevonden voorbeeld hier, waar ze een dergelijke aanval op RSA laten zien).

Het feit dat ze vermoeden dat AMD processoren ook kwetsbaar zijn voor een dergelijke aanval vind ik dan ook niet vreemd. Ik vermoed dat andere SMT processoren zoals POWER en SPARC hier ook vatbaar voor zouden zijn, al is het met slechts twee threads op een core zoals in Intel en AMD's x86 implementaties wel waarschijnlijk makkelijker om het te meten.

Overigens is dit "lek" wel van een geheel ander (minder) kaliber dan de Spectre/Meltdown varianten. In dat geval was er een werkelijk direct lek van informatie/data uit speculatieve executie. In deze situatie gaat het slechts om dat het gedrag van het andere proces enigsinds meetbaar is, maar worden er niet direct waarden uitgelezen. Door het gedrag te analyseren kan wel bepaalde informatie worden achterhaald; stel dat de code "if(x>0) { A } else { B }" doet bijvoorbeeld, dan kan je wellicht meten welk pad meestal genomen wordt, en zo indirect afleiden dat x wel of niet groter dan 0 is.

[Reactie gewijzigd door Squee op 30 juli 2024 19:52]

[robvanwijk]

Het feit dat ze vermoeden dat AMD processoren ook kwetsbaar zijn voor een dergelijke aanval vind ik dan ook niet vreemd. Ik vermoed dat andere SMT processoren zoals POWER en SPARC hier ook vatbaar voor zouden zijn, al is het met slechts twee threads op een core zoals in Intel en AMD's x86 implementaties wel waarschijnlijk makkelijker om het te meten.

Maar dan moet je wel heel goed letten op een subtiel verschil; veel mensen gebruiken "simultaneous multithreading" (en "hyperthreading") als algemene naam voor alle processoren die aan meerdere threads tegelijk werken. Hoewel het de meeste voorkomende methode is (in "consumenten CPUs"), zijn er ook alternatieven, zoals "interleaved multithreading". Ik heb de paper niet in detail bestudeerd, maar in elk geval op het eerste gezicht zou een processor met interleaved multithreading niet vatbaar moeten zijn voor deze aanval:

quote: https://en.wikipedia.org/...ingle-threaded_processors

For real-time applications, a barrel processor can guarantee that a "real-time" thread can execute with precise timing, no matter what happens to the other threads, even if some other thread locks up in an infinite loop or is continuously interrupted by hardware interrupts.

Let wel even op dat de "no matter what happens to other threads" niets zegt over cache misses (en onder het volgende kopje wordt verder op de problemen van caches ingegaan).

Het is een tijdje geleden dat ik de details helemaal uitgezocht heb, maar SPARC maakte in elk geval oorspronkelijk geen gebruik van SMT maar juist van IMT; áls dat nog steeds zo is en áls het niet fout gaat bij de cache, dan zou SPARC dus juist niet vatbaar zijn.

[Squee]

Maar dan moet je wel heel goed letten op een subtiel verschil; veel mensen gebruiken "simultaneous multithreading" (en "hyperthreading") als algemene naam voor alle processoren die aan meerdere threads tegelijk werken. Hoewel het de meeste voorkomende methode is (in "consumenten CPUs"), zijn er ook alternatieven, zoals "interleaved multithreading". Ik heb de paper niet in detail bestudeerd, maar in elk geval op het eerste gezicht zou een processor met interleaved multithreading niet vatbaar moeten zijn voor deze aanval:

De definitie die Wikipedia aanhoudt voor SMT is dat je instructies van meerdere hardware threads moet kunnen issue-en in een cycle, dus strict genomen sluit dat dat soort barrel architecturen uit opzich Maar zelfs in dergelijke designs zou ik niet uitsluiten dat je bepaalde 'cross-talk' kan meten tussen de threads; niet de competitie voor executie resources zoals je hier ziet in deze studie, maar wellicht wel effecten in de caches, of branch predictors (al zijn barrel architecturen meestal zo doodsimpel dat ze die niet eens hebben).

Het is een tijdje geleden dat ik de details helemaal uitgezocht heb, maar SPARC maakte in elk geval oorspronkelijk geen gebruik van SMT maar juist van IMT; áls dat nog steeds zo is en áls het niet fout gaat bij de cache, dan zou SPARC dus juist niet vatbaar zijn.

Voor mij waarschijnlijk iets minder dan een 'tijdje' geleden omdat ik totdat Oracle de designers naar huis stuurde vorig jaar, de afgelopen paar jaren aan de ontwikkeling van SPARC meewerkte Vanaf SPARC T4 was het core design volledig out of order en dual issue (en SPARC M8 ging naar quad-issue), en dus volgens de Wikipedia definite wel puur 'SMT'. Daarom verwacht ik dat daar zeker wel wat interacties meetbaar zouden kunnen zijn. Er zijn wel bepaalde fairness mechanismen in de core die het wellicht lastiger zouden kunnen maken, maar daar kan ik niet verder over uitweiden want dat is waarschijnlijk gevoelig Oracle IP.

De eerste generaties Niagara cores (T1 tot T3) ben ik iets minder tot in de (fijnste) details mee bekend, maar ondanks dat het in-order pipelines waren, hadden die ook geen stricte "barrel" scheduling, maar het kwam wel altijd op hele fijne interleaving neer; als ik me goed herinner waren er altijd strand-switches op branches en geheugen instructies, de cores hadden geen branch predictor en namen altijd non-taken aan. Maar ik zou nog steeds niet willen uitsluiten dat daar ook bepaalde sharing-interacties te meten zijn; voor bepaalde long-latency operaties zoals floating point, of de effecten van instructie of data cache misses in een andere strand. T2 en T3 hadden twee integer pipelines en waren effectief dual-issue van twee verschillende strands, dus ook echt 'SMT'.

[Reactie gewijzigd door Squee op 30 juli 2024 19:52]

[Sp3ci3s8472]

De aanval gebruikt de technologie van processors met Simultaneous Multithreading, of SMT. Daarom verwachten de onderzoekers dat ook AMD-processors die dit ondersteunen, kwetsbaar zijn.

Ze hebben een proof-of-concept op GitHub gezet en Intel Security op 1 oktober ingelicht over hun bevindingen. Intel heeft op 1 november een patch vrijgegeven. Volgens een van de onderzoekers was het doel van het onderzoek om een einde te maken aan het gebruik van SMT, omdat dit inherent onveiligheid met zich mee zou brengen. OpenBSD schakelt daarom HyperThreading uit bij komende versies van het besturingssysteem.

Hebben ze AMD dan ook 1 oktober ingelicht? Beetje vreemd dat als ze verwachten dat bij AMD de aanval werkt ze dit niet aan ze melden.

[Loggedinasroot]

Ze hebben het nooit op een AMD processor getest. Dus dat zullen ze eerst wel gaan doen.

[Verwijderd]

In dat geval zijn ze stupide bezig. Of je zegt dat je nog aan het testen bent, of je houdt je mond er over, of je zorgt dat je al getest hebt, maar je gaat niet zeggen 'Ik verwacht dat het bij X ook zo is' terwijl je X nog niet eens getest noch op de hoogte gebracht hebt....

[bwerg]

Of je zegt dat je nog aan het testen bent, [...], of je zorgt dat je al getest hebt

Het is niet alsof een onderzoeker de tijd en middelen heeft om even alle merken en soorten CPU's te testen, dus dit verwijt is lekker gemakkelijk.

of je houdt je mond er over

Wat heb je daaraan, als je aan de nu beschikbare informatie gewoon kan beredeneren dat het bij AMD waarschijnlijk ook werkt?

[robvanwijk]

Je leest de post van MicBenSte verkeerd; er wordt duidelijk een derde optie genoemd:
Mailtje naar Intel "we hebben een bug in jullie processoren ontdekt" (zoals ze gedaan hebben) én een mailtje naar AMD "we hebben een bug in Intel processoren ontdekt en vermoeden dat jullie processoren ook kwetsbaar zijn; kunnen jullie er zelf even naar kijken, want komende maand gaan we de PoC voor Intel openbaar maken".

[Noel]

Die boys zijn toch gesubsidieerd met overheidsgeld, daar wordt vaak onzinniger dingen mee gedaan dan effectief te investeren in het onderzoek. Dus doe het ff goed en bouw even een 400€ test setup.

Laster, eerroof, koersmanipulatie, eigen reputatie, reputatie van universiteit,... legio redenen om je studie goed te doen en je niet te wagen aan gokjes.

[Remenic]

Dus die onderzoeker had niet alle middelen, maar de informatie moest zo snel mogelijk naar buiten gebracht worden omdat deze onderzoeker anders mogelijk niet met de eer kon strijken? Bang dat een ander het ook zou ontdekken en meteen naar buiten zou brengen? Het steentje kon ook niet overgedragen worden aan iemand die meer tijd had, want de ego van de onderzoeker stond in de weg? Tijdsgebrek is gewoon nonsense.

Wat is nou echt een goede reden om zo'n lek naar buiten te brengen voordat alle partijen, waarvan wordt verwacht dat ze getroffen zijn, zijn ingelicht?

[uqrax]

Van belang is vooral of ze AMD vooraf hebben ingelicht. De artikelen op tweakers en ZDNet schrijven hier echter niet over.

Het is jammer maar begrijpelijk dat de onderzoekers niet de mogelijkheid hadden om binnen redelijke termijn alle processors te testen, naast Intel. Maar als ze zeker genoeg zijn van hun zaak om te melden dat AMD "zeer waarschijnlijk" hetzelfde beveiligingsprobleem heeft, horen ze ook AMD ruim van tevoren te hebben ingelicht. Althans, als het doel daadwerkelijk was om ons aller beveiliging te verbeteren.

[Freyaldo]

Hoeveel merken naast intel hebben Hyperthreading? Echt dit voeld als non argument. Dat je zegt we gaan niet alle intels/amd's/whatever's testen lijkt me logisch maar op zijn minst 1 (recente) amd had echt wel gemogen.

Of op zijn minst "amd, dit zijn onze bevindingen bij de processor van jullie concurent, we hebben helaas niet jullie cpu getest, dit mogen jullie zelf doen als jullie denken dat het relevant is. (Wij denken dat het namelijk ook jullie processoren treft) "

[fastedje]

Volgens mij heeft de ThunderX-2 4 SMT threads per hardware core. Deze CPU is echter op het moment nog niet/bijana niet in productie systemen te vinden.

[bantoo]

Je hoort zelden een onderzoeken zo een sterke stelling nemen. Het lijkt me sterk dat Intel danwel AMD SMT aan de kant gaat zetten, het is een moeilijke balans tussen performance en beveiliging.

[Neut72]

Zo werkt het natuurlijk niet.

"Beveiliging" zoals het genoemd wordt is in dit geval hetzelfde als "privacy". Iemand die een computer draait met hyperthreading is vanaf nu dus iemand die feitelijk al zijn privacy opgeeft (tot-en-met zijn pincode aan toe).

[blorf]

De aanval berust op het laten uitlekken van data door de execution engine sharing voor SMT

Dat gaat zonder fysieke toegang plus execute permissies waarschijnlijk niet lukken.
Geen idee hoe het volledig werkt, maar je loopt volgens mij in ieder geval ook nog tegen het OS thread scheduling systeem aan die per situatie zelden dezelfde toestand heeft. Als je een sleutel oid wil bemachtigen door data-uitwisseling tussen threads te manipuleren moet je tot in detail weten wat er op dat moment gebeurt.

[bwerg]

Dat gaat zonder fysieke toegang plus execute permissies waarschijnlijk niet lukken.

Waarom niet? Nou weet ik de details van dit specifieke geval niet, maar sommige side-channel aanvallen lopen gewoon via javascript.

Als een aanvaller zijn script alleen op dezelfde fysieke core moet laten draaien als de gelekte informatie, is het gewoon wachten tot de CPU dat zo schedulet. Het zal weinig met permissies te maken hebben.

[Reactie gewijzigd door bwerg op 30 juli 2024 19:52]

[blorf]

Hoe wil je remote kwaadaardige threads aan het draaien krijgen en afstemmen op lopende processen zonder permissies te hebben waardoor je sowieso al alles kan doen wat je wil, inclusief wachtwoorden onderscheppen enzo?
Via webcontent kun je ongetwijfeld threads veroorzaken, maar op afstand tast je volgens mij compleet in het duister wat betreft target threads die lokaal uitgevoerd worden.

[Reactie gewijzigd door blorf op 30 juli 2024 19:52]

[R4gnax]

Via webcontent kun je ongetwijfeld threads veroorzaken, maar op afstand tast je volgens mij compleet in het duister wat betreft target threads die lokaal uitgevoerd worden.

Via JavaScript kun je het aantal cores wat op een machine beschikbaar is opvragen en vervolgens kun je voldoende kwaadaardige web-workers aanmaken om deze cores te verzadigen. Er zit in principe geen limiet op het aantal web workers en met alle browsers zijn deze vrij te spreiden over alle beschikbare cores.

Vervolgens luister je gewoon naar alles. Wet van de grote aantallen zegt dat je op een gegeven moment jackpot hebt.

[Reactie gewijzigd door R4gnax op 30 juli 2024 19:52]

[Alfa1970]

De kern van het probleem is dus dat je met behulp van Javascript veel te veel informatie kan verkrijgen.
Feitelijk moet het onmogelijk zijn om met behulp van JavaScript deze informatie te achterhalen.
Dit betekend dat de implementatie van JavaScript in browsers inherent onveilig is en zo spoedig mogelijk aangepast zou moeten worden.

Ik wil niet beweren dat de onderliggende hardware problemen niet moeten worden aangepakt, maar het feit dat je op afstand dit kan bewerkstelligen is een veel groter en schadelijker probleem in mijn ogen.

[R4gnax]

De kern van het probleem is dus dat je met behulp van Javascript veel te veel informatie kan verkrijgen.
Feitelijk moet het onmogelijk zijn om met behulp van JavaScript deze informatie te achterhalen.
Dit betekend dat de implementatie van JavaScript in browsers inherent onveilig is en zo spoedig mogelijk aangepast zou moeten worden.

Ik wil niet beweren dat de onderliggende hardware problemen niet moeten worden aangepakt, maar het feit dat je op afstand dit kan bewerkstelligen is een veel groter en schadelijker probleem in mijn ogen.

Dus; alles op het web maar weer terug naar single-threaded?
Dat gaat nooit gebeuren.

Overigens; na de details wat meer gelezen te hebben, lijkt het lek in kwestie niet - zoals in geval van Spectre en Meltdown - gevoelige informatie te lekken. Het toont enkel timing verschillen die kunnen hinten naar verschillende executie-paden binnen code van een andere thread die simultaan op dezelfde hardware core draait.

Je moet, zoals blorf ook aangaf; dus inderdaad behoorlijk wat kennis hebben van de processen die er op een systeem actief zijn om hier iets mee te kunnen. Je kunt een heleboel data van over het hele web aggregeren en daarin zoeken naar 1 bepaald bekend patroon om daar bingo te halen. Maar gewoon enkel een hoop data op zich; daar kun je niets mee.

Om dat te laten werken moet je wel een voldoende grote poel gebruikers hebben met soortgelijke software-omgeving. Dat gaat voor consumenten-omgevingen gewoon niet praktisch zijn. Zakelijke omgevingen die naast een set bekende continue draaiende processen ook web-content actief in een browser draaien; daar zou misschien iets te behalen zijn.

Het feit dat deze gevoeligheden bestonden is ook al hee---l lang bekend en wordt zelfs gezien als 'by design'. Het hele onderzoek lijkt een beetje van de 'water is nat' orde te zijn.

[Reactie gewijzigd door R4gnax op 30 juli 2024 19:52]

[Alfa1970]

Ik doelde feitelijk op de door jou aangedragen mogelijkheid om met behulp van JavaScript het aantal cores van een CPU te achterhalen op afstand.

Niet het feit dat javascript al dan niet multithreaded kan draaien.

[R4gnax]

Ik doelde feitelijk op de door jou aangedragen mogelijkheid om met behulp van JavaScript het aantal cores van een CPU te achterhalen op afstand.

En waarom zou dat gegeven schadelijk zijn?

[Alfa1970]

Omdat je dat de kennis geeft om te bepalen wat je moet doen om deze aanval remote op te kunnen zetten.
In feite zou het op geen enkele manier mogelijk moeten zijn om detaillistische gegevens van een remote systeem te achterhalen met client side scripting.

[Reactie gewijzigd door Alfa1970 op 30 juli 2024 19:52]

[R4gnax]

Omdat je dat de kennis geeft om te bepalen wat je moet doen om deze aanval remote op te kunnen zetten.
In feite zou het op geen enkele manier mogelijk moeten zijn om detaillistische gegevens van een remote systeem te achterhalen met client side scripting.

Je kunt ook gewoon 500 workers starten en daarmee alle CPUs verzadigen die er praktisch in een consumenten-systeem zullen zitten.

Het aantal cores verbergen win je niets mee. Je benadeelt er alleen maar de eerlijke ontwikkelaars mee die deze informatie enkel willen gebruiken om threading zo af te stellen dat ze jouw systeem niet compleet overweldigen...

[Alfa1970]

Als eerlijke ontwikkelaar hoef je helemaal niet te weten hoeveel cores een systeem heeft. Je kan makkelijk honderden threads draaien op 1 core, dat is helemaal het probleem niet.
Het enige dat je mogelijk zou kunnen bepalen met het volstouwen met threads is de hoeveelheid vrij geheugen die op moment van starten van die threads beschikbaar was.
Maar uiteindelijk is het resultaat daarvan dat de boel helemaal vastloopt, en dat is nu niet iets dat een malafide programmeur niet wil, want die wil niet laten weten dat hij iets aan het doen is dat niet door de beugel kan, die wil zo stealthy mogelijk zijn.
En precies dat wordt erg moeilijk als je geen detaillistische gegevens over de hardware van een remote systeem kan verkrijgen zonder dat systeem om zeep te helpen.

[R4gnax]

Als eerlijke ontwikkelaar hoef je helemaal niet te weten hoeveel cores een systeem heeft.

Onzin. Er zijn legio toepassingen waar het heel handig kan zijn om een vast aantal lang-lopende workers te hanteren waarbij de throughput geoptimaliseerd is tov het aantal cores in je systeem.

[Alfa1970]

Ik betwist niet dat het handig is, het is alleen niet noodzakelijk, zeker niet als de thread scheduler in de runtime goed z'n werk doet.
Daarnaast ruil ik graag een beetje performance in voor een zeer groot security probleem.

[R4gnax]

Ik betwist niet dat het handig is, het is alleen niet noodzakelijk, zeker niet als de thread scheduler in de runtime goed z'n werk doet.
Daarnaast ruil ik graag een beetje performance in voor een zeer groot security probleem.

Kennis hebben van het aantal fysieke cores is niet een 'zeer groot security probleem'.

[Alfa1970]

Gegeven deze vulnerability en de noodzakelijkheid tot het weten van het aantal cores om de aanval succesvol te kunnen doen, lijkt het mij een zeer groot security probleem dat ik graag inruil voor een paar percentile performance.

[R4gnax]

Gegeven deze vulnerability en de noodzakelijkheid tot het weten van het aantal cores om de aanval succesvol te kunnen doen

Het aantal cores hoef je helemaal niet te weten. Je kunt net zo goed een 100 tal workers spawnen die gegarandeerd meer cores gaan bezetten en volladen dan er in een consumenten-PC beschikbaar zijn.

Je bent nu enkel bezig met een zinloze éénmans-kruistocht.
Maar ga vooral door tegen windmolens te vechten, als je daar blij van wordt.

[bwerg]

Hoe wil je remote kwaadaardige threads aan het draaien krijgen en afstemmen op lopende processen zonder permissies te hebben

Het hele idee van side-channel is nou net dat het niet via de gangbare kanalen loopt waarvoor permissies nodig zijn.

Natuurlijk is een aanval dan nog steeds niet eenvoudig maar de aanname dat je threads niet bij elkaars data kunnen gaat dan gewoon niet meer op. Als je elk stukje javascript wat je draait moet wantrouwen, heb je wel een probleem.

[Reactie gewijzigd door bwerg op 30 juli 2024 19:52]

[RGAT]

Zo werkt het dus exact wel
Het is altijd een afweging tussen risico en kosten, je kan van iedereen wel zeggen dat je moet kiezen tussen beveiliging OF privacy, alsof ook maar 1% die keuze A of B maakt...
Ook jij maakt die keuze door hier op Tweakers te zitten en je mening te delen, Google Analytics en alle andere tracking toe te staan en uberhaupt met internet verbonden te zijn, daarmee kies je voor gebruikersgemak ipv beveiliging.

Vraag mij overigens af hoe je je pincode verliest dankzij een lek in Hyperthreading, hoe gebeurt dat als de pincode nooit op de computer wordt ingevoerd maar op een Rabo Scanner bijv.?......

[Dafader]

Ik kan bij ABN zonder scanner etc. betalingen doen. IBAN+Pasnummer+pascode..

[Frogmen]

Klopt naar rekeningen waar je eerder naar hebt overgeboekt anders niet. Je moet wel het hele systeem noemen anders is het onzin wat je zegt.

[Dafader]

Ok, als ik toch al gehacked ben en ze uit zijn op mijn bankgegevens en email, geld overmaken naar mijn paypal waar ik eerder geld naar heb overgemaakt(kan men zien in mijn afschriften of emails die ze in kunnen zien met mijn IBAN en pascode) en dan naar een rekening van een kwaadwillende. Wel een beetje doordenken voor je onzin verlaren wil.

[daemonix]

Correctie: OpenBSD heeft het in de huidige versie al uitgeschakeld. Je moet het in 6.4 bewust aan zetten in plaats van uit.

[Toettoetdaan]

Lol; 'We denken dat het ook werkt op AMD' maar we hebben AMD niet ingelicht

[VittunWasted]

Blijkbaar zijn er wel wat vereisten om dit werkbaar te maken. Geen frequency scaling of turboboost jne voor hun proof of concept. Afwachten wat ze nog vinden...

[STFU]

Hyperthreading lijkt me tegenwoordig ook niet meer zoveel toevoegen met de huidige aantallen cpu-cores.

[Berlinetta]

Toch wel handig als je gaat virtualiseren.

[mae-t.net]

Met 16 cores is het een koud kunstje om gewoon 2 fysieke cores aan een VM toe te wijzen, en voor een moderne server is 16 al niet eens veel meer.

[CH4OS]

Dr Sky- en Kaby Lake processoren hebben anders ook niet veel cores. Dat is echt de nieuwe trend, maar het gaat juist om (iig) de íets oudere producten.

[t link]

Ik denk ook niet dat dit gigantisch belangrijk is voor consumenten. degene die zich zorgen moeten maken zijn shared hosting providers en andere cloud aanbieders.

[lonegunner]

als dit al in 2005 bekent was, waarom brengen ze dan nog steeds nieuwe cpu's met HT uit?(zonder beveiliging patch)

[ShellGhost]

Hoe kom je bij die conclusie? Ik kom namelijk tot een hele andere.
Dat de patches voor CVE-2005-0109 voor die bug wel werken, maar voor deze niet.

[bwerg]

Dat staat er toch gewoon bij? Voor de toen bekende aanval waren er fixes, en de huidige aanval is dus niet hetzelfde.

Anders dan die techniek heeft PortSmash echter niets te maken met subsystemen van het geheugen of caching. De fixes voor de aanval uit 2005 werken dan ook niet, aldus de onderzoekers.

[lonegunner]

dacht dat werking van de de ht van de i7 920/960 en ht van i7 8700 zelfde werkte,ben er niet zo in thuis

[Bozebeer38]

Apart, smt protocol was al sinds vorig jaar uitgezet door microsoft in windows 10 in de fall update of net erna.

[RGAT]

Dat was SMB1, het filesharing protocol, nogal iets anders dan een processor feature 'SMT'

[Ayporos]

lol idd.. ik dacht al 'waar de heck heeft die kerel het over'.

Wanneer ik taskmanager open op mijn windows 10 bak zie ik toch echt bij 'aantal cores' het aantal 'thread cores', niet fysieke cores.

[Bozebeer38]

Ja my bad, al die afkortingen.

[Loggedinasroot]

Ik ben benieuwd of dit ook op AMD werkt. Gezien Intel een paar jaar terug al adviseerde om HT uit te zetten op Skylake processoren omdat er bugs waren.

En ook omdat de multi threading implementatie van AMD beter presteert dan de Intel HT. Dus er zullen wel wat verschillen in zitten.

[ToolBee]

"Ze verwachten dat PortSmash, zoals de aanval is genoemd, ook werkt op AMD-processors."

2e zin ook lezen!

[Wim-Bart]

Verwachting is ongelijk aan daadwerkelijk. Eerst een proof of concept zien dan geloven. Tot die tijd werkt het dus niet op AMD.

[bwerg]

Tot die tijd werkt het dus niet op AMD.

Vanuit veiligheidsoogpunt is 'we hebben het nog niet fout zien gaan dus het zal wel goed gaan' natuurlijk niet per sé de meest handige redenering.

[madmaxnl]

Geldt dit ook voor 256b AES? Ben het verder met je eens hoor, ga maar gewoon uit van meerdere 0 days in hard- en software.

[Reactie gewijzigd door madmaxnl op 30 juli 2024 19:52]

[Wim-Bart]

Dat is geen argument in mijn beleving, Je moet eerst kijken of het lek er daadwerkelijk is voordat je aanname kan doen en beschuldigend kan wijzen. Straks krijgen we weer dat er hoaxes de wereld in worden gebracht die opeens waarheid worden. En daar zit niemand op te wachten,

[smiba]

Ja maar het is dus niet getest

"Verwacht dat" != "Het is zo"

[Reactie gewijzigd door smiba op 30 juli 2024 19:52]

[Loggedinasroot]

Als je het verhaal van de onderzoekers leest, dan lees je ook dat ze niks op AMD processoren hebben getest.
Iets verwachten is iets dan dat het ook daadwerkelijk zo is.