MIT beschrijft Pacman-aanval die geheugenbescherming Arm-soc omzeilt

Beveiligingsonderzoekers van MIT hebben een hardwarematige kwetsbaarheid in een beveiligingsmechanisme van Arm-chips zoals Apples M1-soc ontdekt. Ze beschrijven hoe deze te misbruiken is bij een aanval om de geheugenbescherming te omzeilen.

De onderzoekers van het MIT Computer Science & Artificial Intelligence Laboratory beschrijven in een paper hoe ze er in slaagden om de zogenoemde pointer-authenticatie van Arm-chips te omzeilen met behulp van speculatieve uitvoering. Ze demonstreren hun bevindingen met een aanval op de geheugenbescherming van een M1-soc van Apple. Tegenover The Register meldt de onderzoeker dat voor de M1 gekozen is omdat dit de eerste desktopprocessor met Arm Pointer Authentication is.

Deze beveiligingstechniek is sinds 2017 bij de komst van Armv8.3 aanwezig in de chiparchitectuur. De kans is groot dat ook andere Arm-socs zoals die van Qualcomm en Samsung kwetsbaar zijn. Een pointer verwijst naar geheugenadressen en manipulatie maakt dat potentieel gevoelige data te achterhalen is en code uitgevoerd kan worden. Cryptografische handtekeningen met de naam pointer authentication codes, of PAC's, moeten manipulatie voorkomen.

De MIT-onderzoekers gebruikten een sidechannel-aanval om achter resultaten van de PAC-verificatie te komen. Daarbij maakten ze gebruik van de engine voor speculative execution om waarden te 'raden'. Processors werken met speculatieve uitvoering om de uitkomst van berekeningen vast gereed te hebben voor ze daadwerkelijk nodig zijn, om zo de uiteindelijke verwerking te kunnen versnellen. Ook bij Spectre en Meltdown werd deze eigenschap ingezet voor aanvallen.

Om een Pacman-aanval uit te kunnen voeren, is een al bestaande softwarekwetsbaarheid vereist, wat de impact wat inperkt. Eenmaal uitgevoerd is het wel mogelijk om code op kernelniveau uit te voeren en een systeem volledig over te nemen, aldus de onderzoekers. Ze demonstreren hun aanval tijdens het International Symposium on Computer Architecture in New York, dat 18 juni begint.

Reacties (75)

[Mizgala28]

Maar als de M1 dit probleem heeft, dan neem ik aan dat de A chips van Apple in iPhones en iPad dit probleem dan ook hebben?

[berchtold]

Vast wel. Maar iOS is een stuk meer dichtgetimmerd. Zal daarop waarschijnlijk niet gaan tenzij hij gejailbreaked is

[well0549]

Een exploit is genoeg hoor, kunnen ze Apple nog zo dicht timmeren maar als je het aan het internet hangt, maakt het niet zo heel erg veel uit dat je als gebruiker bijna niets mag....

Voor een habbekrats kun je exploits kopen

[zvbhvb]

Voor een habbekrats kun je exploits kopen

Ja om een Facebook account te hacken of een laptop.

Geen Pegasus a €200000 om een willekeurige iphone 13 uit te lezen.

[nullbyte]

Wat versta jij onder het hacken van een laptop?

[zvbhvb]

Het hele proces dat je toegang geeft als gebruiker/admin/system van een willekeurige laptop.

[well0549]

Dat zijn zero touch zero day vulnerabilities....

Andere vulnerabilities zijn een stuk goedkoper

[DefaultError]

Dat betekent dat als het op hardware niveau niet dicht getimmerd is dit met het OS opgelost, patch, gaat worden. Net als bij Spectre en Meltdown zal het OS deze manke verhelpen. Dit gaat ten koste van de prestaties.

Ben benieuwd of de ‘brand new’ m2 architectuur kwetsbaar is. Dat is iets om rekening mee te houden als ze over willen naar m3 versie. Als het al op te lossen is in de bestaande ontwerpen.

De exploits zitten gelukkig doorgaans niet in de gebruikelijke structuren van het net. Je hebt maar één exploit nodig om de boel overhoop te halen. Een gerichte mail en verwijzing kan serieuze gevolgen hebben. En het telefoontje, sir you are calling from Apple HQ. We noticed….. Tuut tuut.

[beerse]

Zie dit dan als een handvat om die jailbreak wel uit te voeren.

[Groningerkoek]

Totaal andere cpu's

[well0549]

Lekker dan, hoop niet dat arm dan trager gaat worden als er een fix komt....

Bij Spectre en meltdown hadden de fixes en behoorlijk negatieve invloed op de performance

[beerse]

De negative invloed van de spectre en melt-down patches op de performance was in de regel niet te meten, laat staan dat ze het konden merken. De negative invloed was er vooral als het systeem tot de grens van de performance wordt geduwd. Dat gebeurt in de praktijk niet echt vaak. En als dat wel gebeurt, grijpen na enige tijd andere zaken in.

Mijn idee; dat hele predictive execution uit schakelen. Het zou een performance winst kunnen opleveren maar het is ook extra cpu-gebruik en genereert dus ook warmte. En tegenwoordig wordt er wat meer op energie misbruik en warmte ontwikkeling gelet.

[Reactie gewijzigd door beerse op 26 juli 2024 00:28]

[Azbest]

Yeah right, als je alleen games speelt misschien nog. Als je gaat compilen of renderen merk je wel degelijk verschil.

God dank dat je die onzin eenvoudig kan uitzetten met Linux. Die patches zou ik alleen gebruiken met apparaten die altijd verbonden zijn met het internet.

[well0549]

Of als je op een overbelaste hypervisor zit

[latka]

Nog trager serieus: deze beveiliging kost zonder mitigatie al cpu cycles (voor gebruik van een signed poiubter moet je de cpu vragen deze te controleren). Las ergens iets over 16 cycles voor pointer auth. Signen was ook niet gratis. Ik heb niemand gehoord over het performance verlies bij het gebruik van signed pointers dus het lijkt me sterk dat mensen het nu wel ineens een probleem vinden.

[Groningerkoek]

Begrijp ik het goed dat men en toegang tot een useraccount moet hebben, en er reeds een andere exploit/lek aanwezig dient te zijn en men gezien de methode de laptop fysiek in bezit moet hebben?

Indien zo, kan ik hier echt niet wakker van liggen en als een fix de laptop trager maakt mogen ze die van mij wel vrijwillig maken in plaats van forceren.

[Zer0]

Indien zo, kan ik hier echt niet wakker van liggen

Jij misschien niet, maar beheerders die apparatuur in gebruik geven aan gebruikers kijken er anders tegen aan.
Maar ook jij zou er "wakker van moeten liggen"
Dit houdt ook in dat je laptop bijvoorbeeld kwetsbaarder is als je de grens over wil steken en de douane graag op je device wil rondneuzen.

[Reactie gewijzigd door Zer0 op 26 juli 2024 00:28]

[Groningerkoek]

Ik zeg dan ook nergens dat anderen er ook niet wakker van liggen, en als er een fix is kan een ieder die dat wil deze installeren.

[Zer0]

Als je apparaat aan internet hangt zou het gewoon een geforceerde update moeten zijn. Jij denkt wellicht dat er geen gevaar is voor jou, maar anderen kunnen er ook last van ondervinden als je device deel uit maakt van een botnet.

[Groningerkoek]

Als de voorwaarden om dit uit te kunnen buiten zoals ik die veronderstel juist zijn dan zullen er niet veel van deze machines in een botnet opduiken door deze methode. En de kans dat mij dit overkomt acht ik 0,0 dus als het prestatie kost heb ik graag de keuze om dit niet te doen.

[InjecTioN]

Veel mensen hebben geen idee wat een dergelijke kwetsbaarheid op grotere schaal op kan leveren. Dat is eigenlijk wel duidelijk aan je nogal nonchalante - en wellicht kortzichtige - opmerking hierover.

De kans dat je onderworpen wordt aan de gevolgen (malware) van een dergelijke kwetsbaarheid is relatief groot. Iedereen krijgt er wel eens mee te maken. Niet specifiek door je eigen toedoen, maar voornamelijk door buitenstaanders. Je bent tenslotte met je apparaat verbonden met een netwerk van andere apparaten (het hele internet).

Bezoek maar eens een geïnfecteerde website, die normaliter als veilig bestempeld wordt. Er hoeft simpelweg slechts gebruik te worden gemaakt van malware die zichzelf, door een zero-day vulnerability in de browser die zichzelf administrator/root-privileges weet te verschaffen, welke nog niet bekend is bij de ontwikkelaars van je gebruikte browser, en je bent direct nat.

Malware wordt meestal, zonder het op te kunnen merken, geïnstalleerd. Het kan iets simpels zijn als een crypto-miner, iets schadelijker zoals een botnet (wat op grote schaal veel rekenkracht maakt en schadelijk is over de hele wereld - waar jij tenslotte onvrijwillig aan mee zou werken), of iets schadelijks als een crypto-locker - wat je data (permanent?) vergrendelt en/of verzamelt.

Bovenstaande malware zorgt er tevens voor dat je alsnog, weliswaar onvrijwillig, prestaties (en meer) inlevert. Je bent dus niet alleen onverstandig om aan het gaan met je eigen data, maar indirect ook met andermans data. Je ziet het bij een apparaat met lokale symptomen waarschijnlijk niet als een grootschalig probleem. Echter ben je hierdoor, wegens de connectiviteit met "het grote boze internet", wel zelf onderdeel van het probleem. Wellicht een stukje onwetendheid, maar er liggen genoeg gevaren op de loer bij het afstruinen van het internet, waar het grootste deel van de mensheid geen weet van heeft.

Malware zie je in allerlei vormen en maten. Voorheen werden ze eerder bestempeld als virus, maar dat brengt eigenlijk alleen maar verwarring met zich mee. Malware wordt (net als virussen) dus gewoon door een (of meerdere) persoon gemaakt. Het is dus een stukje software dat moedwillig iets stuk probeert te maken, in opdracht van de maker.

[Reactie gewijzigd door InjecTioN op 26 juli 2024 00:28]

[Groningerkoek]

Om dit probleem uit te buiten is er fysieke toegang tot mijn laptop nodig...

Leuk dat je mij onwetend, kortzichtig en nonchalant noemt terwijl je zelf een volledig irrelevant verhaal ophangt over "je hoeft maar een website te bezoeken..."

[zvbhvb]

Juist niet!

Het is een hardware bug die op afstand uit te buiten is.Een voorwaarde is wel nog een bug (software/hardware) zodat je zonder het systeem te laten crashen ( direct, bruteforce ..), sidechannel de pac probeert te achterhalen. En hardware kun je niet zomaar even "patchen".

[Groningerkoek]

alsof een dergelijke patch niet relevant is omdat er iets aan prestaties ingeleverd moet worden

Jij leest dingen die ik nergens schrijf.

Ik geef aan dat ik persoonlijk geen patch tegen deze kwetsbaarheid hoef als ik daardoor prestaties inlever, jij verzint vervolgens je eigen waarheid omtrent mijn woorden en verdraait dit tot "alsof ik een patch hiertegen ook voor anderen niet relevant vindt. En dat is onzin, andere usercase andere wensen, voor mij persoonlijk is deze specifieke aanval een niet boeiende mogelijkheid.

Het lijkt erop dat je er geen idee van hebt over hoe veranderlijk alle websites kunnen zijn.

Jij moet ophouden met te bedenken wat ik wel of niet weet en je moet begrijpend leren lezen. Ik heb het overduidelijk over de aanval waar dit artikel over gaat, en daarvoor is het irrelevant wat ze allemaal op websites weten te plaatsen want voor deze aanval is fysieke toegang tot mijn laptop nodig want de aanval kan niet op afstand worden uitgevoerd.

[Reactie gewijzigd door Groningerkoek op 26 juli 2024 00:28]

[latka]

Wat je alleen vergeet is dat signed pointers de boel al vertragen. Dus überhaupt het gebruik ervan kost je al een tijdlang cpu performance. Om dan nu te roepen dat de patch optioneel moet zijn want performance is vreemd imho.

[Groningerkoek]

Waarom zou ik vergeten dat een extra beveiliging enige vertraging oplevert? Alleen kunnen we deze beveiliging zelf niet patchen of uitschakelen omdat die hardwarematig zit ingebakken en zou er om dit te voorkomen dus een extra voorziening elders moeten komen om de veiligheid van de beveiliging te herstellen en het is afwachten of en zo ja hoeveel prestatieverlies zoiets oplevert.

[latka]

Nee, de beveiliging bestaat eruit dat de de programmeur (of de compiler) overal waar met pointers gewerkt wordt een "sign pointer" of "checkpointer" instructie toevoegt. De hardware doet het signen/verifiëren. Maar software geschreven zonder deze instructies is rapper. Niemand heeft geklaagd dat Apple dit is gaan gebruiken terwijl het een lapmiddel is voor een andere klasse van bugs (pointer confusion). Dus als die klasse van bugs de nek omgedraaid zou zijn was deze 'hack' niet nodig zijn en je machine dientengevolge nog rapper.

[Groningerkoek]

Deze beveiliging is reeds een vast gegeven, dus hoe de laptop zou zijn als deze beveiliging nooit was geïntroduceerd is niet meer relevant voor mij, want hij is er en blijft er op mijn laptop.

[Djerro123]

Ik heb niet het idee dat er nonchalant wordt gedaan over de gevaren van malware of internet in het algemeen. Zijn opmerking is; als de fix mij meer kost dan het mij oplevert in risico vermindering, dan zou hij graag die afweging zelf willen kunnen maken.

Niks mis mee toch? Ik heb het idee dat Groningerkoek een mening wordt aangepraat die hij helemaal niet aan het uiten is…

[Groningerkoek]

Yep, ik acht de kans dat mijn laptop in handen komt van iemand die deze moeite wil en kan doen echt extreem klein, daarnaast ben ik op dat moment mijn laptop toch al kwijt en zou ik als een laptop na diefstal terugkomt toch al een volledige nieuwe schone installatie doen waarbij het probleem gelijk weer verholpen is.

[Zer0]

Zijn opmerking is; als de fix mij meer kost dan het mij oplevert in risico vermindering, dan zou hij graag die afweging zelf willen kunnen maken.

Het probleem is alleen dat net als bij besmettelijke ziektes "hij" niet de enige is die risico loopt.

[Djerro123]

Kromme vergelijking natuurlijk. Bij een besmettelijke ziekte is de volgende persoon ook vatbaar voor de ziekte. In deze casus gaat het niet om malware maar om een exploit. Als deze exploit succesvol op de ene laptop wordt uitgevoerd, ben je nog geen stap dichterbij om dezelfde exploit op een totaal andere laptop uit te voeren.

[Zer0]

Je bent echter wel dichter bij het misbruiken van de geexploiteerde pc om andere zaken te verpsreiden. Denk aan opnemen in een bot, of als springboard gebruiken om een bedrijfsnetwerk te infilteren.

[cnieuweboer]

Waarom is er fysiek toegang nodig tot de laptop? Wellicht lees ik er over heen, maar ik zie de eis niet en het lijkt me niet heel logisch.

[zvbhvb]

Geen fysieke toegang nodig dus.

MIT was able to perform the PACMAN attack remotely. “We actually did all our experiments over the network on a machine in another room. PACMAN works just fine remotely if you have unprivileged code execution,”

bron:https://www.macworld.com/article/708912/mit-pacman-m1.html

[Groningerkoek]

PACMAN works just fine remotely if you have unprivileged code execution

En hoe krijg je dit

[cnieuweboer]

In de uitleg van MIT in het bericht waar je op reageert staat "MIT was able to perform the PACMAN attack remotely". Een remote attack betekend dat er geen fysieke toegang nodig is. Het is me nog steeds niet duidelijk waarom je zegt dat er fysieke toegang tot de computer nodig is.

Code execution betekend alleen maar dat er een programma uitgevoerd moet worden. Dat zegt niets over hoe die code uitgevoerd moet worden. Er zijn bijvoorbeeld genoeg beveiliging problemen in webbrowsers geweest die remote code execution mogelijk maakten.

[Reactie gewijzigd door cnieuweboer op 26 juli 2024 00:28]

[Groningerkoek]

Pac-Man werkt op afstand, maar daarvoor is eerst de optie nodig om code uit te mogen voeren en tenzij ik als gebruiker jou deze rechten geef gaat je dat niet lukken op dit moment zonder fysieke toegang. Daarnaast is het nog de vraag of Pac-Mac volledig geautomatiseerd kan worden of dat er menselijke interactie nodig blijft om het gehele proces te doorlopen van een Pac-Man aanval.

[cnieuweboer]

Om pacman remote en zonder toestemming uit te voeren heb je een ander beveiliging lek voor nodig die remote code execution mogelijk maakt. Dat staat ook in de laatste alinea van het nieuwsartikel. Dat heeft invloed op de directe impact van pacman, maar zegt niets over fysieke toegang.

Beveiliging problemen zijn niet allemaal het zelfde. Remote code execution exploits kunnen niet altijd privilege escalation, en privilege escalation exploits kunnen niet altijd remote code execution. Maar je kunt exploits wel combineren.

Voor pacman is het nodig code uit te kunnen voeren, maar hoe dat precies gebeurd is niet belangrijk, en geen onderdeel van pacman zelf. Pacman doet alleen een soort van privilege escalation, niet de remote code execution. En je kunt niet zomaar stellen dat voor alle remote code execution exploits fysieke toegang nodig is.

[Groningerkoek]

En je kunt niet zomaar stellen dat voor alle remote code execution exploits fysieke toegang nodig is.

Ik stel: tenzij ik als gebruiker jou deze rechten geef gaat je dat niet lukken op dit moment zonder fysieke toegang.

[cnieuweboer]

Met bijvoorbeeld CVE-2022-0289 was dat niet nodig.

[Groningerkoek]

Met bijvoorbeeld CVE-2022-0289 was dat niet nodig.

Ik stel: tenzij ik als gebruiker jou deze rechten geef gaat je dat niet lukken op dit moment zonder fysieke toegang.

[cnieuweboer]

Dat punt geef ik je, maar ik zie niet hoe het relevant is. Een punt maken over bekende remote code execution exploits in software die jij op dit moment op jou computer gebruikt, en mijn persoonlijke capaciteiten als hacker, wijkt enorm af van "men gezien de methode de laptop fysiek in bezit moet hebben" en mijn vraag over die fysieke toegang.

[Groningerkoek]

Dat we weer terug bij het begin zijn, of ik geef rechten of men heeft mijn laptop nodig.

[zvbhvb]

Wat jij zegt klopt wel, je zal eerst remote op jouw systeem iets uit moeten kunnen voeren, Dat kan iedere legitieme gebruiker door jou ingesteld zijn. Dus wordt het moeilijker en dat was de bedoeling. Een extra obstakel.

Punt was :je moet fysiek toegang hebben

En dat is niet altijd waar.

Relevant is betrekkelijk, alles is risico analyse en garanties bestaan niet.

[cnieuweboer]

Dat je zelf zover afdwaalt van je originele punt betekend niet dat de reacties en vragen die over dat originele punt gaan niet gesteld zijn. Dat betekend dat we terug zijn bij het moment voor je zover afdwaalt. Dus "Met bijvoorbeeld CVE-2022-0289 was dat niet nodig."

[Groningerkoek]

Ik heb het over nu, niet over een paar maand geleden.

[Accretion]

Als je apparaat niet geüpdatet is, dan draai je nog software van een paar maanden geleden.

Daarnaast, wij weten niet hoeveel remote code execution lekken er vandaag nog zijn.

En je weet simpelweg niet 100% zeker of alles wat je download geen malafide payload heeft.

Je hebt het er steeds over dat je zelf rechten moet geven. Maar laat het nu net zo zijn dat het gaat om privilege-escalation, het verkrijgen van rechten zonder toestemming.

Dat je een entrypoint nodig hebt is waar, maar daar zijn veel verschillende mogelijkheden voor.

[MaDMaRTiGaN648]

Moreover, we show that the PACMAN attack works across privilege levels, meaning that we can attack the operating system kernel as an unprivileged user in userspace

Dat zou dus potentieel ook gewoon vanuit een browser kunnen, door het bezoeken van een kwaadwillinde of geïnfecteerde website.

[Groningerkoek]

Gezien de methode betwijfel ik dat ten zeerste.

[sequenter]

Beetje lullig bedoeld maar ook weer niet helemaal, lees het volgende artikel eens: Dunning-krugereffect

[Groningerkoek]

Nee dank je, ik mis de relevantie. De onderzoekers geven aan dat voor deze methode fysieke toegang nodig is en met die info kan ik meer dan een wikipedia pagina lezen over hoe jij mij incompetent vindt.

[sequenter]

Zeg alleen maar dat je je eigen kennis overschat.
De fysieke toegang verschaf je zelf (gebruiker --> start browser --> ga naar geinfecteerde pagina --> uitvoer exploit)
En voila

[Groningerkoek]

Misschien moet je eerst even lezen hoe deze aanval in zijn werk gaat voordat je nog meer comments maakt.

[dog4life]

Maar waarom zou de methode die @sequenter beschrijft dan niet realistisch zijn, kun je dat uitleggen?

[Zeerob]

@sequenter schrijft: gebruiker --> start browser --> ga naar geinfecteerde pagina --> uitvoer exploit
Maar zo simpel is het niet voor een hacker. Het is niet zo dat je met een 'geinfecteerde pagina' en een 'exploit' zomaar eenvoudig code op een aangevallen systeem kan uitvoeren. Dat kan alleen als er een grote kwetsbaarheid in de browser zit, en het betreffende systeem is niet gepatched.
Leveranciers van browsers zoals Chrome en Edge zitten er bovenop om te zorgen dat zulke kwetsbaarheden er niet zijn.
Dit probleem met PacMan speelt dus alleen als de inbreker al binnen is op jouw systeem. Dan lijkt de extra beveiliging die PacMan biedt dus minder goed te werken. Maar PacMan biedt geen primaire methode om op een systeem in te breken.

[sequenter]

Heren, het gaat er niet om of het nou een browser of een email client of iets anders is. Het gaat erom dat de gebruiker verleid wordt om iets te doen. De browser was maar een voorbeeld.

[dog4life]

Dat is ook mijn punt, een misclick is snel gemaakt en zeker door de minder onderlegde computeraar.

[blorf]

Ik heb het niet gelezen, maar volgens mij moet je software uitvoeren die die branch prediction situatie triggert. Iets wat de permissies heeft om complexe berekeningen direct op de machine uit te voeren. Er zijn vast wel browser-plugins die dat mogen...

[well0549]

Begrijp ik het goed dat men en toegang tot een useraccount moet hebben, en er reeds een andere exploit/lek aanwezig dient te zijn en men gezien de methode de laptop fysiek in bezit moet hebben.

Naar een malafide site gaan en je ligt open

[Groningerkoek]

Dan hebben ze stap 1, stap 2 is mijn laptop in handen krijgen.

[jurroen]

Fijn dat jij daar niet wakker van ligt - anderen doen dat wel. En daarnaast ook: op ARM servers kunnen de gevolgen hiervan vele malen groter zijn dan een single user client device. Maar onderschat dat ook niet - beheerders van omgevingen met gevoelige data moeten hun werk ook vanaf een device doen

[Power2All]

Aangezien het heel makkelijk tegenwoordig is om mensen dingen uit te voeren op hun Mac, net zoals bij Windows, is die kans zeer aanwezig.
Als men eenmaal iets kan executen op je machine, kan je al de sjaak zijn, dus tja... Beetje nitpicken om iets wat tegenwoordig niet meer een reden is om een Mac te nemen, welke te maken had dat er minder virussen zijn dan voor de PC, wat al langer niet meer het geval is.

[Groningerkoek]

Ik persoonlijk acht de kans dat iemand anders mij dit op mijn Mac uit laat voeren echt 0,0 dus de patch is voor mij persoonlijk nog steeds irrelevant.

[Power2All]

Ik acht die kans op mijn Windows bak ook zeer klein tot nihil, maar er is altijd een kans dat het toch eens een keer gebeurd.

[beerse]

Zie het andersom: Zo'n toestel (mobieltje, tablet, laptop, wat dan ook) dat in handen is van iemand anders. Die kan er dan toch wel op inbreken, ondanks dat je het niet verwacht.

Bijvoorbeeld met een versleutelde disk (sd, ssd...), die een keer opgestart door het systeem zelf wel te lezen is. Breek je daar dan op in, dan kan je de disk toch lezen.

[bahamapleister]

Nee dat begrijp je niet goed:

Does this attack require physical access?
Nope! We actually did all our experiments over the network on a machine in another room. PACMAN works just fine remotely if you have unprivileged code execution.

Bron: http://pacmanattack.com/

[Groningerkoek]

if you have unprivileged code execution.

Juist, en hoe krijg je die op dit moment

[djwice]

Stel het is niet een laptop maar een server.
Stel je gebruikt een shared server.
Stel je gebruikt gevirtualiseerde hardware.

[Groningerkoek]

Stel.....

[djwice]

Dan denk ik dat het fijn is dat er op die laag wel een patch wordt uitgevoerd, anders kunnen andere klanten van het platform wellicht succesvol een aanval uitvoeren.

Zoals ook bij de vorige keren. "Je" kon toen bij geheugen van andere klanten van je provider, als je voldoende animo had omdat te doen.

[Reactie gewijzigd door djwice op 26 juli 2024 00:28]

[dieAndereGozer]

Een proces in userspace heb je zo, dus ik zou er wel wakker van liggen.

[Zer0]

misclick

[Reactie gewijzigd door Zer0 op 26 juli 2024 00:28]

[Vic-Green]

mogelijk om code op kernelniveau uit te voeren en een systeem volledig over te nemen

Nonsens