Onderzoekers kunnen via mds-aanval data uit meerdere cores in Intel-cpu's lezen

Onderzoekers van de Vrije Universiteit Amsterdam hebben een nieuwe manier gevonden om data te onttrekken aan verschillende Intel-chips. Het is een vorm van de eerder ontdekte microarchitectural data sampling-methode, met dit keer samplen uit een gedeelde buffer.

Het onderzoek komt van VUsec, een groep beveiligingsonderzoekers aan de VU in Amsterdam. Die noemen het nieuwe lek CrossTalk. De VUsec-onderzoekers borduren met het onderzoek voort op eerder ontdekte kwetsbaarheden in Intel-cpu's, en specifiek de manier waarop chips aan speculative execution doen. Dat is een optimalisatiemethode waarbij een cpu bepaalde taken of berekeningen probeert te voorspellen om de processor sneller te maken. Bij zo'n voorspelling worden line-fill- en store-buffers gebruikt. VUsec-onderzoekers ontdekten eerder al meerdere manieren om data af te lezen uit die buffers.

CrossTalk is een nieuwe manier van die 'data sampling' uit de microarchitectuur van cpu's. Dit keer is er volgens de onderzoekers echter een groot verschil. Voorheen kon de data alleen worden afgelezen uit de buffers op één core. Nu kunnen de onderzoekers echter een line-full buffer aflezen die door meerdere cores in een cpu gedeeld wordt. Met CrossTalk ontdekten de onderzoekers dat sommige requests in een staging buffer werden gedaan die door meerdere cores wordt gebruikt.

De onderzoekers hebben een proof-of-concept gemaakt waarmee ze via een core informatie kunnen aflezen uit Intels secure enclave, de Software Guard Extension of SGX. Het gaat dan bijvoorbeeld om de output van een hardware digital random number generator. Die output wordt bijvoorbeeld gebruikt om cryptografische sleutels te genereren.

De onderzoekers werken al sinds september 2018 samen met Intel om het probleem te verhelpen. Omdat het lek dezelfde soort kwetsbaarheden gebruikt als eerder bekend waren heeft Intel dat in de meest moderne cpu's geprobeerd te voorkomen. Daarom zijn lang niet alle cpu's kwetsbaar.

Intel noemt het lek zelf Special Register Buffer Data Sampling. Het bedrijf heeft een tabel online gezet met de getroffen cpu's. Het lek krijgt de aanduiding CVE-2020-0543 mee. Intel schrijft in een blogpost dat het geen aanwijzingen heeft dat het lek buiten een academische omgeving is misbruikt. Het bedrijf heeft zelf ook een technische uitleg geschreven.

Reacties (50)

[kw4h]

Is dit toevallig gerelateerd aan de ook vandaag uitgekomen 'SGAxe' vulnerability? Zie: https://sgaxe.com/

Edit: Discussie op HN

[Reactie gewijzigd door kw4h op 23 juli 2024 07:40]

[vDorst]

Gisteren heeft Phoronix over dit onderwerp ook meerdere artikelen over gemaakt tevens met een benchmark.
https://www.phoronix.com/...stalk-srbds-vulnerability en https://www.phoronix.com/...Talk-Buffer-Data-Sampling

Benchmark: https://www.phoronix.com/..._item&px=RdRand-3-Percent
En nog een: https://www.phoronix.com/...crosstalk-benchmark&num=1

[Reactie gewijzigd door vDorst op 23 juli 2024 07:40]

[junkchaser]

Ik denk dat ik Intel toch even links laat liggen. Uiteindelijk vragen ze stevig door op hun producten en blijkt dat ze niet zo betrouwbaar zijn als we eerst dachten...

[Rudie_V]

Ik denk dat je al sinds een tijdje kan aannemen dat alle skylake en volgende cpu's allerlei problemen hebben op security gebied en dat een volgende gevonden kwestbaarheid slecht weer kwestie van tijd is en meestal weer een gevolg is van het ontwerp zelf. Vooral in het speculative execution gedeelte waarvan de basis al ver terug te vinden is in de eerste core en misschien al voorgaande ontwerpen en zodoende security misschien nooit echt hoog had staan omdat het nog uit een tijd stamt waar het minder of niet echt speelde. Die ontwerpkeuzes van toen staan nu nog steeds aan de basis van al deze problemen.
Pas met de nieuwe Cove cores (Palm Cove, Sunny Cove, Willow Cove, Gold Cove en Ocean Cove) kan intel dit echt achter zich laten. Maarja, deze cpu's moeten op 10nm gemaakt worden en daar heeft intel grote problemen mee en zodoende moet intel het nog steeds doen met de 14nm reeks die deze problemen in zich heeft.

[Twam]

Ik heb hier een 6600K die inmiddels kennelijk zo lek als een mandje verklaard kan worden

Wat ik zelf eigenlijk vooral storend vind aan dit hele verhaal, is dat Intel het kennelijk allemaal niet serieus genoeg vind om zelf via hun website updates of patch-tools aan te bieden. Je moet eerst zooitje trucs uithalen om uit te vogelen welke microcode-versie je nu hebt en dan vervolgens handmatig via Microsoft de goede update daarbij zoeken om je Intel-microcode te patchen. Ik concludeer daaruit dat ze bij Intel zoiets hebben van 'mwoah, gewone gebruikers mogen best kwetsbaar zijn en serverbeheerders weten zelf wel wat ze moeten doen; wij hoeven hier verder geen rol in te spelen'. Ik vind het beledigend naar je klanten toe en ik snap niet dat de marketingafdeling daar niet (beter) op ingesprongen is.

Met een stuk vocaler oplossingsprogramma hadden ze dit best kunnen ombuigen naar een positieve gebruikerservaring, van het type 'goh, ja problemen komen voor, maar Intel is vet actief bezig om die allemaal op te lossen'. Maar nu is de impliciete boodschap dat ze het allemaal wel gezegend vinden en de problemen in de komende 10 jaar vanzelf weggaan, zolang iedereen braaf de nieuwe series blijft kopen. Niet zo'n goede look, dat.

[rajackar]

Voor een gewone gebruiker is er ook nauwelijks een risico. Je moet als aanvaller nog steeds eerst software op een machine zien te krijgen voordat je iets kunt doen. En deze software zal of wel door een virus scanner opgepikt worden of het is een zero day en dan ben je sowieso het bokje omdat deze niet opgepikt wordt en al je data sowieso al kan stelen, ook zonder deze kwetsbaarheid.

Het is veel nadeliger voor shared infrastructure providers als Azure of AWS aangezien het in theorie mogelijk is om data te stelen uit andere VM instances (van andere klanten) die op dezelfde CPU draaien. Een gerichte aanval is praktisch gezien niet echt te doen omdat je als aanvaller op dezelfde CPU moet draaien als de VM die je wilt aanvallen. Met letterlijk honderduizen zo niet miljoenen CPUs in een regio is die kans zo klein dat het als aanval techniek niet echt nuttig is.
Je zou wel een soort van vangnet uit kunnen werpen en kijken of je iets interessants kan vinden. Dus vanuit een klant perspectief moeten deze lekken gedicht worden om de data veilig te houden. Maar voor een gerichte aanval zie ik niet veel scenario's waar dit nuttig is.

[n00bje]

Voor een gewone gebruiker is er ook nauwelijks een risico. Je moet als aanvaller nog steeds eerst software op een machine zien te krijgen voordat je iets kunt doen.

De oorspronkelijke RIDL (MDS) kwetsbaarheden konden uitgebuit worden met javascript. Dan zal dat in dit geval ook wel zo zijn. Kom je op een website die gebruik maakt van een lakse advertentieboer heb je het mogelijks al vlaggen.

[rajackar]

Dat klopt. Maar als je als aanvaller al zover bent zijn er veel eenvoudigere manieren om data te stelen dan die uit een cpu te peuteren. En voor een gerichte aanval is het nog steeds omslachtig omdat je moet weten waar bijvoorbeeld een encryptie sleutel is voordat je die gericht kan stelen.
Het is zeker belangrijk dat dit soort zaken aangekaart worden en gedicht worden maar voor dagelijks gebruik zou ik me niet al te veel zorgen maken.

[OkarBan]

Side-channel attacks vanuit een browser zijn er wel voor demonstratie doeleinden om te laten zien dat zoiets kan: https://googleprojectzero...me-sandbox-with-ridl.html

Maar in de praktijk is het inderdaad omslachtig omdat het moeilijker is om te detecteren welke hardware je precies hebt vanuit een browser en het heel ander resultaten kan opleveren als je maar net iets andere hardware of VirtualMachine hebt dan waarop de onderzoeker het getest heeft.

[rajackar]

Dat is precies mijn punt idd. Met een stuk kwaadaardige javascript kun je veel makkelijker resultaten behalen op andere manieren

[Argantonis]

Dat is precies mijn punt idd. Met een stuk kwaadaardige javascript kun je veel makkelijker resultaten behalen op andere manieren

Mja, áls je een andere vulnerability gebruikt. Maar dat kan gefixed worden en dat gebeurt meestal ook snel. Het is niet zo dat een stuk javascript dat in de browser draait per definitie ontzettend veel slechts kan op je computer, al helemaal niet als iemand geen grof geld neerlegt voor een zero day om specifiek jou te pakken. Dan zou browsen echt een nachtmerrie zijn.

[Wim-Bart]

Voor deze exploit is een stuk Javascript in theorie al voldoende.

[rajackar]

Zie mijn reactie hierboven

[GoBieN-Be]

Cloud Hypervisors daarentegen ...

[Rudie_V]

Ongepatched is je 6600K kwetsbaar, met patches en de juiste software updates is dat beperkt tot een minimum. Hoewel er volgens mij wel een paar kwestbaarheden zijn gevonden die niet 100% gepatched konden worden gezien het daarvoor veranderingen in het ontwerp zelf nodig heeft.

Volgens mij zie je een aantal zaken toch verkeerd betreffende het beschikbaar stellen van updates en het oplossen van de problemen vanuit intel.
Het 'probleem' is dat microcode wordt geladen vanuit het bios en dat biosupdates altijd weer afhankelijk zijn van de fabrikant. Daarom kan intel geen generieke tools aanbieden die iedereen zou kunnen gebruiken. Voor de bios en de microcode update in het bios ben je dus afhankelijk van je moederbordfabrikant.
Gelukkig hebben bepaalde besturingssystemen het initiatief genomen om microcode updates ook als update in het besturingssysteem uit te voeren dat systemen die geen biosupdates meer ontvangen toch een microcode update van het besturingssysteem kunnen krijgen, deze microcodeupdate is dan natuurlijk alleen maar actief als je het betreffende besturingssysteem draait, niet tijden het opstarten of met andere besturingssystemen(die zo'n patch niet hebben).
Of intel echt laks is met het updaten en dat het intel niets interesseert is jouw persoonlijk mening, ik ben het daar niet geheel mee eens. Hoewel er volgens mij ook wel kwetsbaarheden waren die intel misschien minder belangrijk vond dan de beveiligingsonderzoekers die de kwetsbaarheid hebben gevonden en gemeld, heeft intel toch alles gedaan om de kwetsbaarheden aan te pakken. Dat het beter kan is bijna altijd wel zo, maar intel kan niet veel meer dan een plijster plakken.
Dat intel er schijnlijk niet veel moeite voor doet heeft natuurlijk z'n redenen, het vergt architecturele aanpassingen om het probleem bij de bron aan te pakken en dat zal intel niet in grote moeite meer doen in de afgeschreven ontwerpen, het heeft immers al meerdere opvolgers.. maar die worden uitgesteld door problemen met het 10nm proces. Al intel kan doen is plijsters opplakken op de huidige cpu's en de tijd uitzitten tot men eindelijk 10nm op orde heeft en de nieuwe core ontwerpen uit kan brengen. Ja misschien had intel eerder aan een backport moeten denken om een 10nm Cove ontwerp terug naar 14nm te porten. Gezien de lange tijd die de problemen met 10nm innemen had dat een goede beslissing geweest, maar wel eentje die veel tijd kan kosten en misschien al 1-2 jaar geleden dan had moeten worden genomen en toen had men misschien nog niet voorzien dat de problemen met 10nn zo lang zouden duren.

[Twam]

Naja, daarom heb ik het ook expliciet over de optics van het verhaal - ik ben geen doorgewinterde technicus. Iets betere communicatie en wat vriendelijke tekst op hun Support-pagina had hierin bijvoorbeeld al flink gescheeld, vind ik.

Het microcode-verhaal is op zich wel interessant, want je hebt helemaal gelijk dat de updates bestaan, maar je moet best veel moeite doen om ze te krijgen. Intel steekt dus inderdaad wel de tijd, energie en geld in het maken van die updates, waarvoor hulde, maar waarom doen ze dan zo weinig hun best om daarover te communiceren?

Kijk, dat ze in mijn geval bijvoorbeeld MSI niet zover kunnen krijgen een recentere update dan mid-2018 te maken, dat is natuurlijk puur financieel, snap ik wel. Maar die Windows-updates draaien dus idd op OS-niveau, op basis van de fixes van Intel zelf. Microsoft biedt ze aan via hun website (niet via automatische Windows Update), als executable. Intel biedt wel allerlei executables aan om hun GPU's te patchen (inclusief AMD-link voor die APU's met AMD-GPU's), plus links naar andere downloads die hun producten ondersteunen. Het zou ze sieren als ze dan daar ook links zouden plaatsen naar de relevante Windows-downloads (en evt. downloads voor iOS en grotere Linux-distro's).

Dat producten fouten bevatten vind ik niet direct een probleem, het gaat erom hoe een bedrijf de afhandeling en communicatie daar omheen doet. Technisch doet Intel dat dus gerust OK, maar de communicatie blijft naar mijn mening toch achter - paar honderd dollar in de maand om die info bijgewerkt te houden en de hele beeldvorming is anders.

[Rudie_V]

De vraag is misschien, hoeveel en waar zou intel dan moeten communiceren over hun kwetsbaarheden in hun processors en de microcode updates? Wat zou jij dan aanraden gezien je het benoemt?
In de normale media heeft weinig zin, niemand snap het (even grofweg genomen), laat staan dat ze weten hoe een bios geupdatet moet worden. Alleen als ze de auto-update software van de fabrikant hebben draaien zullen ze misschien de biosupdate krijgen. Misschien daarom wel goed dat microsoft de microcode updates als windows updates uitbrengt, want anders zouden vele systemen niet gepatched worden vrees ik(hoewel de windows update natuurlijk alleen onder windows werkt, maar het gros draait toch windows).
In de technische media wordt dit natuurlijk wel uitgebreid gemeld, besproken en wat je er aan kan doen. Voor de technische mensen is het updaten verder geen probleem. En vanuit intel is aangegeven dat je afhankelijk bent van je moederbordfabrikant voor de biosupdate.

Dat intel wel hun gpu's fixt heeft natuurlijk te maken dat intel de fabrikant van de gpu is en ook verantwoordelijk is voor de software en bios.
Ik snap dat je valt over waarom intel wel links aanvoert naar amd voor hun intel cpu's met amd gpu en waarom ze dan ook niet doen voor hun intel cpu's naar de moederbord fabrikanten. Maar anderzijds kan je stellen dat intel alleen de fysieke hardware, chips, levert en fabrikanten deze op hun eige manier implementeren in hun moederborden met hun eigen biossen, intel levert niet de bios. Ik denk dat je daar naar moet kijken.

[SilverRST]

Niet alleen beledigend naar je klanten toe, maar ook arroganter en achterbaks en ondertussen het lef om de volle mep te blijven vragen. Ik kan hierbij dan ook geen sympathie hebben voor zo een bedrijf.

Gelukkig is AMD weer back in the game en mijn volgende cpu wordt dan toch echt een AMD, ook omdat ik vanaf 1440p game.

[Blokker_1999]

Betrouwbaar zijn ze wel, maar men blijft beveiligingsprobelemen vinden. Dan moet je wel de vraag durven stellen: is de concurentie veiliger, of heeft men daar de bugs nog niet gevonden. Niet vergeten dat vele van de zwakheden die de laatste jaren ontdekt zijn gewoon verderbouwen op eerder gevonden lekken. Mocht men op een gegeven moment bij AMD ook zo een zwakte vinden die een hele keten aan exploits mogelijk maakt, dan sta je ineens zonder CPUs in je computers.

[batjes]

Zelf krijg ik sterk de indruk dat Intel de loop der jaren her en der de weg heeft afgesneden om op die manier een voorsprong te forceren op AMD, vooral als je de exploits zelf leest en dat Intel her en der toch behoorlijk wat performance moet inleveren om het weer veilig te maken. Waar AMD eerder design keuzes maakt die de veiligheid verhogen.

AMD ligt misschien wat minder in het vizier door een kleiner markt aandeel. Maar het is ook niet zo dat de onderzoekers AMD helemaal links laten liggen.

[sygys]

Maar hoe onveilig is het precies? Wat moet je doen om die data uit te lezen? Kan dit met een simpel virus op afstand of moet je daadwerkelijk bijna gaan solderen op de bestaande cpu om deze data eruit te krijgen. Dat wordt me namelijk niet echt duidelijk in het artikel. In de afgelopen jaren heb ik al heel veel "hacks" de revue zien passeren hier. Maar 99% hiervan heeft 50 handelingen van de gebruiker zelf nodig om vatbaar te worden. Dat is in mijn ogen hetzelfde als zeggen dat een slot op een deur niet veilig is als je de deur open zet.

[Verwijderd]

Het is fubar.

https://www.wired.com/sto...ulative-execution-buffer/

"It's kind of like we treat the CPU as a network of components, and we basically eavesdrop on the traffic between them," says Cristiano Giuffrida, one of the researchers in the VUSec group at Vrije Universiteit Amsterdam who discovered the MDS attack. "We hear anything that these components exchange."

That means any attacker who can run a program on a target chip—whether in the form of a malicious application, a virtual machine hosted on the same cloud server as the target, or even a rogue website running Javascript in the target's browser—could trick the CPU into revealing data that should be protected from untrusted code running on that machine. That data can include information like what website the user is browsing, their passwords, or the secret keys to decrypt their encrypted hard drive.

[the_stickie]

zegt nog steeds alleen iets over de potentie, niet over de complexiteit. Veel van de voorbij cpu kwetsbaarheden zijn praktisch onbruikbaar, al was het maar omdat er eenvoudiger manieren zijn om je doelen te bereiken.

[Sp3ci3s8472]

Ze zijn erg onveilig, voor cloud diensten is dit niet leuk. Gezien je daar met een groot aantal mensen dezelfde fysieke hardware deelt. Er is een reden dat een Amazon engineer een "fix" heeft geschreven die het mogelijk maakt om vanuit user space je L1d cache te flushen. Als iemand dat doet op een gedeelde bak dan kan je je performance gedag zeggen.
Linus heeft die fix gelukkig geweigerd, dit soort dingen wil je niet vanuit userspace kunnen doen....

Voor gewone gebruikers zal het wel meevallen, zolang ze dingen zoals noscript draaien in hun browser.

[jbbt]

Als ik het goed begrijp dus als je bijvoorbeeld een keypair genereert je daarna de L1d cache cleared om te voorkomen dat deze afgelezen wordt? Dan is het inderdaad een beetje een domme fix

EDIT: Found it https://lkml.org/lkml/2020/6/1/1700

[Reactie gewijzigd door jbbt op 23 juli 2024 07:40]

[Wim-Bart]

Het is heel simpel. Via je webbrowser kan je in een ander proces inbreken wat op een andere core draait. Op Intel is het gewoon vragen om Problemen zonder dat je het in de gaten hebt.

[Verwijderd]

Mocht men op een gegeven moment bij AMD ook zo een zwakte vinden die een hele keten aan exploits mogelijk maakt, dan sta je ineens zonder CPUs in je computers.

Apple stapt over op ARM dus we krijgen een ronde 3

[Verwijderd]

Er is vandaag gepubliceerd over een side channel attack in een ARM design.

https://www.zdnet.com/art...rare-side-channel-attack/

[Verwijderd]

Mwah, het lijkt voorlopig mee te vallen:

"This would be difficult to exploit in practice, and a practical exploit has yet to be demonstrated," the chipmaker wrote in an SLS FAQ page. However, Arm says that the possibility of a successful practical attack "cannot be dismissed." [...] the company has been working since last year to fix this issue. Is engineers have contributed patches to various software projects and operating systems, including FreeBSD, OpenBSD, Trusted Firmware-A, and OP-TEE. These patches should block exploit attempts at the firmware/OS level.

However, Arm has done more. The company has also contributed patches to GCC and LLVM, two of today's most popular code compilers. The patches are meant to prevent developers from compiling code that may be vulnerable to this attack and limit its spread in real-world code.

Unlike Spectre and Meltdown, Arm says these patches aren't likely to cause any unwanted performance impact.

[supersnathan94]

Dat is wel interessante kost. Lijkt er op dat dit voornamelijk in het CPU design zit. Kans is dus aanwezig dat Apple hier geen last van heeft doordat zij zelf cpu design doen en alleen gebruik maken van de ARM instructiesets. De Apple A-socs zijn in ieder geval niet 1-op-1 gebaseerd op een Cortex-A ontwerp.

[The Zep Man]

Ze zijn prima betrouwbaar, zolang je maar geen beveiligingssegmentering hoeft toe te passen binnen systemen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 07:40]

[Wim-Bart]

Bijvoorbeeld system proces en user processen. Het is dus door deze feature mogelijk om vanuit een user process in een root process te belanden. Wanneer je de mitegatie bekijkt voor een normaal Linux en Windows systeem is dat user en root processen nooit simultaan op twee of meer cores kunnen lopen.

Getroffen CPU's zijn dus eigenlijk in een modern systeem niet meer in te zetten.

[terabyte]

Diezelfde gedachte heb ik ook al een tijdje. Intel CPUs hebben de laatste paar jaar zoveel beveiligingsproblemen, waar vervolgens een software workaround voor verzonnen moet worden die impact hebben op de performance. De extra prijs die je voor nieuw processoren betaalt is het daardoor niet waard.

Met Apple over op ARM denk ik dat nu de tijd is gekomen voor KISS processoren

[3dfx]

Het kan ook zo zijn dat er meer onderzoek naar Intel gedaan wordt omdat ze nog steeds de grootste zijn op de CPU-markt voor PC's en servers.

Een beetje zoals met Windows en macOS: er is meer aandacht voor het zoeken naar zwakke plekken in Windows omdat het marktaandeel veel groter is.

Wat betrouwbaarheid en beveiliging betreft: het online gaan met wat voor machine dan ook is nog het grootste gevaar voor de gegevens daarop, oftewel gewoon je boekhouding blijven doen op een offline ZX-81

[Trommelrem]

Ik heb zo'n vermoeden dat Microsoft al langer bezig is om Intel aan de kant te zetten en met die security incidenten van de laatste jaren krijgt dit project nog eens een boost. Althans, Microsoft doet pogingen daartoe.

De Microsoft Surface RT en Surface RT 2 waren commercieel gefaald, maar technisch geslaagd. Ze kwamen uit in een tijd dat een veelgehoorde klacht van Intel het stroomverbruik was. Sinds de Pentium 4 is Intel alleen maar bezig met performance ten koste van stroomverbruik en wellicht ook ten koste van security.

Toen kwam Microsoft ineens met Windows RT voor ARM processors. De eerste PC zonder ventilatoren en met lange accuduur. Intel werd bang. En hoe toevallig, na de Surface RT 2 kwam Intel wel met energiezuinige processors, waardoor het voor Microsoft voorlopig even niet nodig was om Windows te blijven compileren voor ARM.

Nu komt heel toevallig, na al die security incidenten, de Surface Pro X uit. Wederom denk ik dat de Surface Pro X commercieel geen groot succes zal zijn, maar technisch is de Surface Pro X enorm geslaagd. x86 Applicaties kunnen immers ineens op een CPU met ARM architectuur draaien. De volgende stap zal zijn dat x86-64 applicaties ook op een CPU met ARM architectuur draaien. Het staat allemaal nog in de kinderschoenen, de performance valt tegen, maar Microsoft komt met kleine stapjes steeds verder. Intel beeft. Intel beeft inmiddels uit z'n voegen en zal dus snel iets moeten doen om te voorkomen dat de ARM architectuur voor het Windows platform een werkbaar alternatief wordt.

Intel beeft denk ik volledig terecht. De consument wil geen performance, maar security en accuduur. Als Microsoft de overstap maakt naar ARM, dan heeft Intel een groot probleem.

[Reactie gewijzigd door Trommelrem op 23 juli 2024 07:40]

[koelpasta]

Sinds de Pentium 4 is Intel alleen maar bezig met performance ten koste van stroomverbruik

Eeh, de P4 was een energieslurper 1e klas. Sindsdien is het stroomverbruik per performance juist drastisch afgenomen. Alleen niet zoveel als bij de concurenten.

[Edgarz]

Ach, voor de primaire doelgroep (datacenters) zijn prima alternatieven te vinden in de nieuwe AMD Epyc processors 😉

[Kratos]

Het lijstje met vulnerabilities begint wel lang te worden

[computerjunky]

Wat ik mis is of je hier ook weer lokale toegang nodig heb tot de pc.

Die leaks boeien me namelijk helemaal niets. En al moet ik de eerste patch nog tegen komen die voor mij de prestaties verlagen zou ik deze wel verwijderen als ik ze vind. Vooralsnog lijkt het allemaal niet relevant te zijn voor thuisgebruikers.
Zolang ze namelijk toegang nodig hebben tot mijn pc kunnen ze net zo goed de drive naast mijn scherm meenemen. Daar staat alles op en mijn pc is totaal niet beveiligd dus iedereen die groter is als 1 meter kan bij de aan knop.

[Reactie gewijzigd door computerjunky op 23 juli 2024 07:40]

[bantoo]

Ze hebben toegang nodig tot code execution of je PC. Bijvoorbeeld de tweakers pagina die je op dit moment bezoekt.

[OkarBan]

Vanuit Javascript is het moeilijker te exploiteren,
threads zijn niet altijd ingeschakeld,
SharedArrayBuffer heeft na Spectre beperkingen gekregen en het is moeilijker te detecteren welke hardware je computer precies heeft vanuit javascript. Waardoor de javascript prototypes vaak alleen nog maar op de eigen computer van de onderzoekers werken.

[Reactie gewijzigd door OkarBan op 23 juli 2024 07:40]

[Wim-Bart]

Geen lokale toegang nodig. Een buffer overflow in een plaatje op een site is voldoende, of een Javascript in een Browser. Needs nothing more..

[OkarBan]

Alleen een buffer overflow in een plaatje zonder verdere interactie is dus niet voldoende om een sidechannel attack uit te voeren. Voor buffer overflow kwetsbaarheid kan een volledige Code Reuse Attack bovendien praktischer zijn dan een combinatie met een sidechannel attack. Want voor een sidechannel attack is het maar een beetje gokken wat het precies gaat doen bij een computer van een ander, dus is het twijfelachtig hoe goed het gaat werken met javascript in een browser van iemand anders.

[Reactie gewijzigd door OkarBan op 23 juli 2024 07:40]

[Remenic]

Met een buffer overflow exploit kun je code injecteren welke een sidechannel attack uitvoert.

[OkarBan]

Ouderwets shell code injecteren bij een buffer overflow gaat niet meer zomaar op moderne besturingssystemen, vanwege beveiligingsmaatregelen zoals DEP/W^X, ASLR, etc.

Wat nog wel vaak gebruikt wordt is hergebruik van bestaande code via ROP (Return Oriented Programming) of varianten zoals JOP (Jump Oriented Programming), COP (Call Oriented Programming), COOP (Counterfeit Object Oriented Programming), DOP (Data-Oriented Programming), etcetera, etcetera.

Een combinatie hiervan met een sidechannel zou inderdaad mogelijk zijn, maar zoals eerder genoemd is dit heel fout gevoelig en is de kans veel groter dat het mis gaat en de aanval dus mislukt wanneer er onbekende hardware wordt gebruikt.

[Reactie gewijzigd door OkarBan op 23 juli 2024 07:40]

[computerjunky]

Dus browsers of andere software als game launchers zijn een vereiste en dus is het op te lossen op software niveau in de browser. Als deze niet actief zijn is er dus niets aan de hand als ik het goed begrijp.

[OkarBan]

Als het computer systeem altijd uitstaat, dan is er inderdaad niks aan de hand, maar wie koopt er nou een computer systeem om het 24/7 uit te hebben staan?

De belangrijkste vereiste voor deze Rowhammer&Spectre familie side channel attacks is over het algemeen dat er op een of andere manier er een nauwkeurige teller op de achtergrond is om de tijd softwarematig mee te meten. Dit valt niet makkelijk op software niveau op te lossen, omdat er veel manieren zijn om een nauwkeurige teller te maken, bijvoorbeeld al met een simpele loop die een variabele steeds verhoogt. Maar helaas blijkt in de praktijk ook weer dat de gebruikte methoden niet op alle hardware goed werken.

[Reactie gewijzigd door OkarBan op 23 juli 2024 07:40]

[lordawesome]

Je zal maar een Intel cpu in je server hebben.

[Ventieldopje]

Ben ik even blij dat overal KernelCare draait Verwachten voor zondag een patch te hebben, zonder dat je hoeft te rebooten.

https://blog.kernelcare.c...ing-patched-by-kernelcare