Kwetsbaarheden in Apple-cpu's maken datadiefstal via browser mogelijk

Beveiligingsonderzoekers van de Georgia Institute of Technology en de Duitse Ruhr-Universität Bochum hebben nieuwe kwetsbaarheden gevonden in chips van Apple. Daarmee zijn zogenaamde 'side-channel'-aanvallen mogelijk, waarmee gevoelige data gestolen kan worden.

Beide aanvallen, omgedoopt tot SLAP en FLOP, zijn in papers beschreven door de onderzoekers, die in 2023 ook de iLeakage-kwetsbaarheid vonden. Net als bij iLeakage maken SLAP en FLOP misbruik van een speculative-executionfunctie. Deze functie, die in sommige chips zit, stelt cpu's in staat om alvast bepaalde berekeningen uit te voeren, nog voor ze nodig zijn. Cpu's worden daarmee sneller, maar bepaalde berekeningen worden ook naar de buffercache uitgelekt. Aanvallers kunnen die gelekte data uit de cache uitlezen.

De aanval kan op afstand uitgevoerd worden via een browser, waarin een malafide webpagina geladen wordt. Als gebruikers naar zo'n pagina gelokt worden, is het voor aanvallers mogelijk om gevoelige data te stelen via andere tabbladen. Het gaat dan bijvoorbeeld om events in de iCloud Calendar, locatiegeschiedenis uit Google Maps en inboxcontent uit Proton Mail.

De SLAP-kwetsbaarheid zit in Apple-cpu's vanaf de M2/A15-generatie. De FLOP-aanval treft specifiek de M3-, M4- en A17-processors. De cpu's worden zowel in MacBooks als in iPhones en iPads gebruikt. De onderzoekers hebben Apple in 2024 op de hoogte gesteld van de kwetsbaarheden. Op 24 mei werd Apple ingelicht over SLAP en op 3 september over FLOP.

Apple bevestigt tegenover Bleeping Computer dat het op de hoogte is van de problemen en dat ze deze gaan aanpakken. Vooralsnog is er echter nog geen oplossing beschikbaar. "Op basis van onze analyse zijn wij van mening dat dit probleem geen direct risico vormt voor onze gebruikers", zegt Apple.

Update 12.02: Er stond dat Apple op 24 maart is ingelicht over SLAP, maar dat moet mei zijn. Het artikel is daarop aangepast.

Reacties (92)

[johnbetonschaar]

Hector Martin van Asahi Linux heeft deze kwetsbaarheden verder onderzocht en gereproduceerd, en claimt dat als browsers gewoon de juiste CPU security features enablen, deze kwetsbaarheden in principe geen groot probleem horen te zijn. ARM CPU's hebben ingebouwde security features die timing attacks voorkomen, en uit zijn tests blijkt dat als browsers deze features enablen voor de JavaScript VM (zoals ze al hadden moeten doen), dat de exploits dan niet meer bruikbaar zijn. De prijs die je daarvoor betaalt is dat JavaScript code iets langzamer zal werken, maar dit is volgens hem letterlijk niet te voorkomen op geen enkele CPU, als je maximale performance wil heeft elke CPU optimalisaties nodig die extern observeerbaar zijn (en dus timing attacks mogelijk maken), dus als je untrusted code veilig wil draaien zul je moeten kiezen tussen security of optimale performance.

[1] https://social.treehouse.systems/@marcan

[Reactie gewijzigd door johnbetonschaar op 30 januari 2025 11:50]

[Keypunchie]

JavaScript is een zegen en een vloek. Random sites mogen code uitvoeren op je PC... Tijdlang heb ik NoScript gedraaid, en je wordt er eng van hoeveel van het internet van Javascript aan elkaar hangt. Het werd helaas erg bewerkelijk om alles te whitelisten en dan ben je toch ook weer al je security kwijt.

[Zoop]

NoScirpt gaat haast niet meer tegenwoordig. Er zijn zat frontends die puur op javascript draaien. Krijg je paar regeletjes html die wat scripts inladen maar de rest van de website puur in javascript opgebouwd, denk react en svelte achtige dingen. Maar ook bij gewoon html wordpress sitjes zie je vaak dat functionaliteit van een knop of menu met javascript geregeld wordt en zonder gewoon niet werkt. Of infinite-scroll news feeds die content bij-ajaxen, en dat ook de enige manier is om meer te zien. Dus tsja, je zal er inderdaad helaas aan moeten geloven

Het is een erg toegankelijke en feature-rijke taal, dat is inderdaad een zegen en een vloek. Kan er echt gave dingen mee doen, complete WebGL enabled 3d games direct in je browser. Je kan er ook een cryptominer mee maken die stiekem mee draait en de batterij van je laptop leegtrekt.

[nzall]

Ik denk dat het hele concept van Javascript security moet worden omgevormd. In een moderne wereld is het gewoon onhoudbaar geworden dat iemand gewoon zomaar op miljarden toestellen tegelijk "untrusted code" kan draaien...

Ik vind dat er een systeem moet komen van whitelists moet komen: een pagina MOET aangeven welke domeinen toegestaan zijn om files aan te leveren. Standaard is dat dan enkel het domein en eventuele subdomeinen van de website zelf. Als een website andere domeinen wilt toelaten, moet die dat aangeven via de content security policy header. Dus met andere woorden: ik vind dat content security policy headers verplicht moeten zijn als je iets van een ander domein wilt inladen. Daarnaast moeten gebruikers en browsers in staat zijn om die content security policy te overrulen in geval van misbruik. Dus als Bloomberg zegt: "ik wil advertenties kunnen tonen van Adserve", dan moet Bloomberg in zijn content security policy een expliciete whitelist aangeven voor het Adserve domein. En als dan blijkt dat Adserve op een domein malware aanbiedt, dan kan de beheerder van de overrides list zeggen "sorry Adserve, jij mag voorlopig geen ads meer aanbieden, ook niet op websites die je whitelisten".

[Zoop]

Wat je aanhaalt als advertentie voorbeeld is waarschijnlijk de reden dat het niet zal gebeuren, Google heeft daar gewoon een te grote vinger in de pap. Als dit Ads enigszins bemoeilijkt (de flow of money verstoord) kan je er wel vanuit gaan dat het niet zal gebeuren. En dan zijn advertenties an sich nog vrij onschuldig. Data vergaren en tracking is ook big business.
Dit soort dingen zouden dus vanuit de EU of iets dergelijks gepushed moeten worden.

[jaenster]

Met die gedachte gang kunnen we ook geen docker mee gebruiken. Dat zou ook een sandbox moeten zijn, en als je dat verprutst is dat ook niet veilig. Kwestie van niet verprutsen. Kies voor een browser die veiligheid boven snelheid verkiest.

[Mellow Jack]

Dat zou echt heel slecht zijn. Nu is het redelijk transparant. Als je deze kant op gaat zal iedereen dat soort verkeer gaan reverse proxien en is het ineens niet meer zo transparant waar je data naartoe gaat

[4tro]

Dankzij de push van Google Chrome om geen third party cookies meer te doen is dit al het geval.

[THETCR]

Krijg je paar regeletjes html die wat scripts inladen maar de rest van de website puur in javascript opgebouwd,

Wat denk je dat die scripts zijn? Dat is ook JavaScript.
HTML en CSS leveren je alleen een statische pagina op.
Heel het internet gebruikt JavaScript en een klein beetje WebAssembly

[Zoop]

Krijg je paar regeletjes html die wat scripts inladen maar de rest van de website puur in javascript opgebouwd,
Wat denk je dat die scripts zijn? Dat is ook JavaScript.

Ja duh, html regels die javascripts inladen ja, dat is ook precies wat ik bedoelde

Ben zelf webdeveloper, en het was toch altijd good practice om je HTML dusdanig te bouwen dat het nog fatsoenlijk functioneert als je de css/js weglaat. Dat de content dan nog in een logische leesbare structuur staat, elementen fatsoenlijk aangegeven staan als navigatie enzo, en belangrijkste, alle knoppen (form buttons dus) en links allemaal zo nog steeds functioneren. Want dat is goed voor accessibility, seo en whatnot. Standaard out-of-the-box wordpress site zal dat ook prima doen. En wat is er mis met statische pagina's? Alle dynamische logica gebeurd serverside met php enzo, daar hoeft echt geen frontend javascript bij te komen kijken, en kan prima als statische geserveerd worden. Is dan ook nog eens dik prima te cachen wat hetspulletje een stuk vlotter maakt.

Om de frontend javascript/css afhankelijk te maken is een keuze, absoluut geen verplichting.

[Reactie gewijzigd door Zoop op 30 januari 2025 13:04]

[THETCR]

Het gebruik van JS mag sowieso al niet conflicteren met links en dergelijke.
Een link is een link, een button een button.

PHP... Sorry maar dan kan ik je gewoon niet meer serieus nemen, dan loop je overduidelijk gewoon zwaar achter op de ontwikkelingen binnen web development.
Zelfs Tweakers is begonnen met overstappen op de web component standaard.

[Zoop]

... pardon? Php is nog steeds veruit de meest gebruikte taal, 75%+ Zelfs Python en Javascript zijn veelgebruikte backendtalen.

Web components is frontend, heeft niks met de backend te maken. Dat zal op tweakers ook iets van php of java ofzo zijn. Dus geloof niet echt dat je weet waar je over praat.

En je moet es weten hoeveel form buttons gebruikt worden voor puur alleen wat javascript interactie, of een link met een # als href met hetzelfde. Het "mag" niet, tsja, volgens wie? Die knopjes rechtsboven op tweakers bijv, zijn ook maar een #-link, javascript dat een css-class zet zorgt voor het menuutje dat eruit komt.

[THETCR]

Meen je dit nou echt serieus?
Het is veelgebruikt wegens WordPress, maar echt geen solide basis meer.
PHP werd jaren ontwikkeld door maar 3 mensen en de progressie is gewoon te langzaam.
Daarnaast helpt het opstarten in Apache, request afhandelen en het geheugen weer vrijgeven ook niet mee.

Als ik niet weet waar ik over praat kan ik maar beter mijn lead positie opzeggen en uit alle werkgroepen met Google etc stappen.

Een dooie anchor tag met alleen een # om wat JavaScript uit te voeren is gewoon bad practice. Als je dat niet snapt heb je nog veel te leren.

Je mag me prima even een DM sturen, wil ik je best de huidige standaarden uitleggen.

[Zoop]

Ok, maar leg eens uit wat Web components ermee te maken heeft? En hoe dat het gebruik van PHP beinvloed? Dat mag je best hier even uitleggen hoor. En wat is volgens jouw hetgeen wat PHP opvolgt? Het is achterhaald, dus wat dient iedereen nu te gebruiken dan?

En dat dooie anchor links bad practice is, dat is precies wat ik hier zit te vertellen. Desondanks gebeurd het overal, Tweakers zit er bijv al vol mee. Heel die bovenbalk werkt zo.

[THETCR]

Het ging er mij om dat je als web developer ook gewoon verstand hoort te hebben van hoe web servers werken.

PHP is er van oudsher zeker wel een onderdeel van geweest, omdat de meeste business logica tegenwoordig verschoven is naar de client is het steeds minder gebruikelijk voor engineers om het te kennen.
Maar vroeger kon je er echt niet omheen om gedeeltes in PHP te doen met bijvoorbeeld Symfony.

Rond 2015 is men in de eerste instantie richting Node.js gaan migreren. Wegens het voordeel dat het altijd in het geheugen aanwezig is en dus vele malen sneller is dan een PHP setup (Falcon als PHP framework probeerde dit tevergeefs wat te mitigeren).

Tegenwoordig zien we nu bij grote bedrijven ook een overstap naar Bun.
JAVA wordt wel gebruikt voor API's met Spring enzo, maar niet voor het serveren van de interface naar de client.

[MainframeX]

PHP werd jaren ontwikkeld door maar 3 mensen en de progressie is gewoon te langzaam.
Daarnaast helpt het opstarten in Apache, request afhandelen en het geheugen weer vrijgeven ook niet mee.

Als je hedendaags nog PHP als module in Apache draait met mpm-prefork (zoals je hierboven omschrijft), dan heb je wat mij betreft niet echt verstand van hoe je fatsoenlijk PHP hoort te serveren in 2025 (overigens is dit al jaren de standaard). Dat doe je door Apache in mpm-event process manager te draaien en PHP zelf in de PHP-FPM process manager.

Ik heb geen voorliefde voor PHP, maar ben er wel op tegen dat mensen op nogal houtaine wijze volkomen onjuistheden verkondigen.

[Zoop]

Hah ja zelfde hier, ik zal PHP niet snel verdedigen ofzo. Maar om te claimen dat je niet serieus genomen kan worden als je PHP gebruikt? Dan heb je inderdaad geen idee waar je het over hebt. Ik kies er ook niet voor om vooral in PHP te ontwikkelen, maar dat is waar de klant om vraagt, zeker Symfony, wat gewoon booming is op het moment.
Ik zie PHP nog niet snel van zijn troon gestoten worden in ieder geval.

[MainframeX]

Symfony en Laravel worden gewoon ontzettend veel gebruikt, ook voor nieuwe projecten. Dat is wat ik om me heen zie als DevOps engineer die regelmatig hosting constructies moet optuigen voor projecten van behoorlijke omvang en budget. Java en Springboot en de tig Javascript frameworks zelfde verhaal eigenlijk.

Doordat het zoveel gebruikt vind je er ook relatief makkelijker programmeurs voor; het is aanzienlijk makkelijker om PHP, Java en JS programmeurs te vinden, dan Ruby bijvoorbeeld.

Zelfde verhaal in de DevOps/kubernetes contreien waar ik in zit; hier kunnen relatief veel techneuten in Python en Golang schrijven.

Maargoed, terug on topic; nee PHP is niet een outdated of een of andere hobby taaltje. Hier geldt toch wel echt; this many people can't be wrong. Als je zou willen heb je tot je pensioen werk met PHP denk ik, mocht er niet een andere hippe nieuwe taal super mainstream worden.

[Reactie gewijzigd door MainframeX op 30 januari 2025 19:43]

[THETCR]

PHP leeft nog wegens het gebruik in WordPress en de website boertjes die er al decennialang hun zaken mee doen.
De taal ontwikkeld zich niet zo vlot als andere partijen.

Het is overigens veel goedkoper tegenwoordig om mensen in dienst te nemen die puur JS gebruiken voor zowel de web backend als front-end.

[THETCR]

En hoe komt de klant met de vraag om het in PHP te doen?

[THETCR]

Ongeacht de process manager is het geen constante event loop.
Ongeacht of je PHP-FPM met NGINX gebruikt.
Dat was het hele punt en is nog steeds van toepassing.

[Zoop]

Ok, nogmaals dan: Wat heeft web components met de gebruikte backendtaal te maken?

[THETCR]

Dat staat in de andere reactie die ik heb geplaatst.
De verschuiving van de business logica in de backend met PHP naar de client is een wezenlijk verschil.

[Zoop]

Noem het dan nog eens want ik heb het niet zien staan.

Point being als je claimed dat je niet serieus genomen kan worden met php of dat het achterhaald zou zijn, dan heb je echt geen enkel idee waar je het over hebt. Simpel als dat.

[THETCR]

Goed verhaal. Hoe lang ben je hier al mee bezig?
PHP is wel degelijk achterhaald.

Je gebruikt zeker Prettier en geen linting, maar denkt wel dat je kwaliteitscontrole hebt?

[Zoop]

Ok, nogmaals, antwoord dan de simpele vraag: als php achterhaald is, wat moet je dan gebruiken?

[Menesis]

Ik had laatst een website gemaakt voor een eigen projectje. Iedereen meteen vragen welk CMS of service (webflo) zooi ik had gebruikt. Nee. Gewoon HTML+CSS.

[Zoop]

Dat kan uiteraard, als je verder geen dynamische content zoals een blog/newsfeed of whatever erop wilt, en zelfs dan kan je ook gewoon je html bijwerken om zoiets te doen, maar besef wel dat dit voor de gros van website eigenaren ondoenlijk zal zijn. Wel eens dat lang niet alles een CMS hoeft te hebben. Heb best wat sites gemaakt dat eigenlijk meer een veredelde digitale poster is, met een cms backend erachter om het te kunnen beheren... wat ze dan vervolgens nooit doen ... dus een statische html pagina had voor een hoop van dat soort dingen eigenlijk prima geweest. Stuk zuiniger in onderhoud (zeker als je wordpress voor zoiets gebruikt, moet je wel constant updaten en zelfs dan glippen er regelmatig exploits tussendoor) en hostingkosten. De beste SEO is nog altijd een snelle website. Aan pure HMTL valt er weinig te optimaliseren, je server kan dat gewoon direct serveren, veel vlotter dan dat wordt het niet.

Maar mijn punt was meer, je kan er alsnog een gigantisch gecompliceerd CMS achter hebben hangen, en dan nog heb je niet per se css/js nodig op je frontend om iets functioneels te hebben. Dat is dus nog steeds een keuze, ongeacht hoe ingewikkeld de backend is.

[CH4OS]

Heel het internet gebruikt JavaScript en een klein beetje WebAssembly

DIt is wel wat gechargeerd gezegd. De moderne websites van tegenwoordig gebruiken zogenaamde single page application (SPA) architectuur. Dat betekend dat je 1x een HTML pagina laadt, dat vervolgens de rest van de content (HTML) via Javascript opgehaald wordt. Maar in principe hoeft niet elke website op die manier te werken, doet Tweakers bijvoorbeeld ook niet.

[THETCR]

Er wordt dan nog steeds JavaScript gebruikt. Dus dat punt is nog steeds hetzelfde.

[CH4OS]

Nee, dat hoeft dus niet per se met Javascript te zijn, Tweakers heeft dat momenteel ook niet bijvoorbeeld.
Voor het plaatsen van reacties op de FP wordt bijvoorbeeld weer wel Javascript gebruikt, maar het is echt niet zo dat elke website alleen kan functioneren met Javascript, dat is gewoonweg niet waar namelijk en dus is het punt onterecht.

Nieuwe reacties zie je alhier immers ook alleen na een page refresh. Met Javascript zou zelfs dat niet hoeven (zie de reacties bij forumtopics).

[Reactie gewijzigd door CH4OS op 30 januari 2025 14:43]

[THETCR]

Waar jij het over hebt omtrent de reacties is reactivity, dat stelt niet dat het gebruik van JS wel of niet van toepassing is.

HTML5 en CSS3 bieden je alleen wat mogelijkheden voor korte transities en dergelijke. Alle overige functionaliteit zal je toch daadwerkelijk met JavaScript of WebAssembly moeten doen.

[CH4OS]

Ja, maar je kunt prima een website bouwen dat niet Javascript only is, Tweakers is dat immers ook niet. Alleen door de manier waar bepaalde websites mee gemaakt zijn, die dus praten met een remote API bijvoorbeeld, werken voor de rest vaak wel met Javascript. Dat zijn immers ook de Single Page Apps. Omdat je met de index.html (bij wijze van spreken) de benodigde Javascript laadt.

[Reactie gewijzigd door CH4OS op 3 februari 2025 23:12]

[THETCR]

Wat bedoel je met JavaScript only?

[CH4OS]

Dat de page dan alléén werkt met JavaScript aan. Dat is waar de hele thread over gaat, toch?

[THETCR]

In principe zou de volledig DOM gewoon moeten laden.
Maar dat is niet waar we heen bewegen, met de komst van de Web Components is het de bedoeling dat websites meer als mobiele apps gaan werken.
Maar zonder JavaScript werkt niks daarvan.

[Zoop]

De volledige DOM die niet uit veel meer dan een paar <script> tags bestaat, ja, Dat is wat hier gezegd word.

Hoe bedoel je niet waar we heen bewegen? Juist met het gebruik van web components is dat exact waar je heen gaat. Maar dat het de "bedoeling" is dat websites meer als mobiele apps gaan werken, lol, volgens wie? Ik zie juist een sterke terugkomst van heel die gedachte. Bedrijven zijn ook lang niet meer geïnteresseerd in Apps of App-achtige websites, dat was echt even een hype dat wel weer een eind over is.

Web components heeft minder dan een tiende procent gebruik (en populariteit is alweer aan het zakken) en lang niet iedereen deelt de filosofie dat alles maar als apps moet werken. Dat je verderop staat de claimen dat PHP achterhaald is (en dan juist Web Components aanhaalt als reden, deze hebben geen reet met elkaar te maken), vraag ik mij toch echt af waar je al je "expertise" vandaan haalt. Niet de huidige realiteit, in ieder geval.

Niks tegen web components overigens, is prima spul, maar het verplicht je gelukkig niet om je website als een app te laten werken zoals je hier claimed. Het is gewoon een handig iets dat in principe niks nieuws biedt, tal van frameworks dat soortgelijke functionaliteiten al lang bieden. Het is gewoon handiger als er native support voor dat soort spul is. Maar niks ervan beinvloed de backendtaal (web components kan je prima met php voeden of genereren) of dicteert hoe de site moet functioneren. Wel maakt het je afhankelijker van javascript, wat een keuze is. Het stuurt ons zeker niets in een bepaalde richting ofzo, daar is het aandeel simpelweg te laag voor.

Echt, ik zag je eerder claimen dat dit je werk is, wat doe je dan? Verkoper mag ik hopen? Daarvan ben ik wel gewend dat ze uit hun nek lullen namelijk.

[batjes]

Het maakt het een stuk lastiger om websites uit te lezen d.m.v. scriptjes en zo veel taken te automatiseren.

Het internet is er niet beter op geworden.

[Zoop]

Soms ook niet, als zo'n script netjes met een api praat voor zijn data, dan kan jij dat wellicht ook (en dus zelfs directer dan html uitlezen en dom parsen enzo). Maar dat is vrijwel alleen zo als dat met opzet gedeeld wordt.

[Faloude]

Lijkt helaas wel die kant op te gaan.

[Keypunchie]

Gelukkig ben ik al jaren van Google search af. Eigenlijk alleen nog "mail' als directe service (stuit niet op technische, maar praktische bezwaren: dat email staat overal geregistreerd...).

[Martijntjeh]

Kan ik in de instellingen op mijn mac en iPhone een vinkje omzetten om dat in orde te maken? Of is dat iets wat Apple moet doen?
Ik ben namelijk laatst weer eens door de instellingen van Safari gegaan na een artikel op bright, maar wat je noemt ben ik niet tegengekomen. ( Kan heel goed aan mij liggen…..)

[johnbetonschaar]

Nee niet dat ik weet, dit is iets dat in Safari zelf moet worden ingebouwd (en ook in Chrome en Firefox blijkbaar). Dus je zult moeten wachten op een update van Apple.

Ik zou me er persoonlijk niet heel druk om maken voor nu, het is echt extreem hypothetisch dat je voor die tijd met precies deze exploit getarget gaat worden. Er zijn de laatste jaren al verschillende van dit soor vulnerabilities voorbij gekomen op verschillende platforms, en tot nu toe is er voor zo ver mij bekend nog geen enkel geval bekend dat er daadwerkelijk gebruik van gemaakt is voor ordinaire cybercrime (wellicht wel door geheime diensten/overheden of wat dan ook, denk aan Pegasus achtige dingen, maar dat zijn niet echt dingen waar ik me persoonlijk heel veel zorgen over maak ;-)).

[The Zep Man]

De prijs die je daarvoor betaalt is dat JavaScript code iets langzamer zal werken, maar dit is volgens hem letterlijk niet te voorkomen op geen enkele CPU, als je maximale performance wil heeft elke CPU optimalisaties nodig die extern observeerbaar zijn (en dus timing attacks mogelijk maken),

Maximale prestaties uit applicaties waar externe verbindingen voor toegestaan worden. Je hebt niets aan een timing attack als je het resultaat niet naar buiten krijgt. Zo zou een offline spel prima optimalisaties kunnen hebben die wat onveiliger zijn als het spel verder geïsoleerd is van de buitenwereld.

[johnbetonschaar]

Ja mee eens, het is gewoon een issue van trusted vs untrusted code, waarbij 'trusted' afhankelijk is van de context. Er zijn genoeg manieren om er redelijkerwijs van uit te gaan dat game code die op een client draait niet zonder dat de gebruiker er weet van heeft door een aanvaller is gecompromitteerd, dus onnodig om zoiets als die 'data independent timing' bit zoals ARM CPU's hebben aan te zetten. Maar voor JavaScript die via het web binnenkomt zonder waterdicht trust model is het wel aan te bevelen.

Ik voorzie dat er in de toekomst wel oplossingen komen (of misschien zijn die er al) om JavaScript/WASM code te signen/notariseren zodat de browser er zeker van kan zijn dat de maker vertrouwd is en de bron en integriteit van de code gegarandeerd zijn, en op basis daarvan dit soort security features wel of niet aan kunnen zetten.

[Loller1]

De FLOP-aanval treft specifiek de M3-, M4- en A17-processors.

Vreemd dat de A18 niet getroffen wordt door deze kwetsbaarheid? Of is dat eerder bedoelt als "A17 en later", maar dan waarom M4 benoemen en het gebruik van "specifiek".

[Keypunchie]

In tabel 1 van het artikel zie je welke CPU's ze bekeken hebben en welke kwetsbaar zijn (of in ieder geval, Load Value Prediction ondersteunen, die ze vervolgens gaan exploiten).

M2 MacBook Air (A2681) ✗
M3 MacBook Pro (A2918) ✓
M4 iPad Pro 7th Gen. (A2926) ✓
A15 Bionic iPhone 13 Mini (A2481) ✗
A16 Bionic iPhone 14 Pro Max (A2651) ✗
A17 Pro iPhone 15 Pro (A2848) ✓

De A18 is simpelweg niet bekeken. Vermoedeliijk hadden ze gewoon niet zo'n device makkelijk beschikbaar voor testen. Wat dat betreft klotst in de wetenschap het geld niet om de oren.

[SunnieNL]

Op basis van onze analyse zijn wij van mening dat dit probleem geen direct risico vormt voor onze gebruikers

Serieus?? Je kunt gewoon personal data via een website/browser uitlezen en je zegt dan dat er geen direct risico is... hoezo zie je dat als bedrijf niet als een zeer groot risico? Zijn er zo weinig devices verkocht met een M3, M4 en A17 processor? Volgens mij gaat het om miljoenen mensen die hier kwetsbaar voor zijn.

[Reactie gewijzigd door SunnieNL op 30 januari 2025 11:40]

[CorbataGames]

Het gaat niet om het aantal mensen, maar om de impact ervan als er wel misbruik gemaakt wordt.

Data uit een ander tabblad uitlezen op het moment dat je op een malafide website terechtkomt, geeft een beperkt risico. Het is van een ander niveau dan wanneer er bijvoorbeeld bestanden van je hardeschijf uitgelezen kunnen worden.

Desondanks natuurlijk wel fijn als het snel opgelost wordt.

[SunnieNL]

Data uit een ander tabblad uitlezen op het moment dat je op een malafide website terechtkomt, geeft een beperkt risico

Je stuurt een attacklink per email, Gebruiker opent deze. De website waar je op komt opent een tweede tab naar bv je agenda van Apple. SSO zorgt dat je er vanzelf in komt en ondertussen leest de andere pagina de boel uit.
Het is niet heel lastig om daar misbruik van te maken. Het aantal mensen vergroot het risico/impact omdat de kans dat er iemand op klikt ook veel groter wordt.

[Reactie gewijzigd door SunnieNL op 30 januari 2025 11:55]

[johnbetonschaar]

Het 'probleem' met dit soort kwetsbaarheden is dat het vrij lastig is om binnen redelijke tijd grote hoeveelheden data uit te kunnen lezen, en al helemaal als je gericht in hele specifieke data geinteresserd bent. Dit soort kwetsbaarheden is dan ook niet erg bruikbaar om op grote schaal in te zetten, het is vooral hypothetisch interessant voor gerichte aanvallen op high-profile doelwitten. Plus dat ze bij Apple waarschijnlijk al weten dat ze op zeer korte termijn een update zullen pushen die het lek dicht. Vandaar 'geen groot risico' (wat niet hetzelfde is als 'geen enkel risico').

[Zoop]

Imo ben je dan al een probleem verder, je zit met een gebruiker die op phishing links klikt. Ook zonder browser exploits valt daar genoeg nare shit mee te doen.

Is een beetje dat je bang bent dat de TV in je woonkamer gejat wordt, terwijl je constant de voordeur open laat staan. Het issue is niet met steelbaarheid van die TV ...

Uiteraard moet dit nog steeds fatsoenlijk opgelost worden, maar wel eens dat de impact miniem is als dit je enige attack vector is. En zelfs krijg je iemand zo ver met phishing, dan is het nog geen simpele manier om maar ff wat data te vergaren, er komt behoorlijk meer bij kijken en zal dus praktisch niet in massa toegepast worden maar op individuen. En dus nogmaals, als je die zover kan krijgen om in je phishing val te laten vallen, dan heb je het toch echt over een ander probleem dan deze browser exploit.

[CorbataGames]

Dat tweede tabblad openen blokkeert je browser als het goed is al.

Wat bij mij op elk moment van de week open kan staan in mijn browser kan eigenlijk geen kwaad als dat uitgelezen kan worden. Om daar misbruik van te kunnen maken, zijn weer nieuwe exploits nodig. Kunnen zien wat ik deze maand als afspraken heb staan (Google calendar altijd open in een tab) levert weinig echt risico op.

Maar laten we dan stellen: het risico is beperkter, in plaats van beperkt.

[fastedje]

Toch hoor je regelmatig dat mensen geld.zijn kwijtgeraakt van hun bankrekening omdat er een Session Cookie is gestolen, dus beperkt zou ik het risico zeker niet noemen. Ook al is de kans erop wellicht niet heel hoog, de gevolgen kunnen zeer groot zijn.

[CorbataGames]

Dat kun je m.i. weer een exploit bij de bank noemen.

[laptopleon]

Dan moet je dus minimaal ingelogd zijn bij de bank, niet uitloggen en precies in die paar minuten de foute website bezoeken, en dan nog zal de bank verlangen dat je eerst een qr-code scant met je telefoon en de bank-app opent en expliciet akkoord geeft voor een betaling die je niet aangevraagd hebt.

Als het al zo eenvoudig werkt als het artikel laat lijken, want alle eerdere keren dat ik de moeite genomen heb om de onderliggende onderzoeken te lezen, was het eindeloos veel ingewikkelder. Meestal zijn er allerlei specifieke voorwaarden die allemaal moeten meezitten. Het is goed dat er mensen mee bezig zijn en hier wordt echt wel serieus naar gekeken door Apple.

[SG]

Maar dan ben je al in de val gelopen aangezien je op malafide site zit.
Phishing mail.

[Quilt]

Of dat de malafide content als advertentie op een bonafide site draait.

[dehardstyler]

Data uit een ander tabblad uitlezen op het moment dat je op een malafide website terechtkomt, geeft een beperkt risico. Het is van een ander niveau dan wanneer er bijvoorbeeld bestanden van je hardeschijf uitgelezen kunnen worden.

Net alsof je geen hele spannende data in een browser tab kunt hebben? Zo beperkt is dat nou ook weer niet? Ik bedoel wat voor iets spannends heb jij op je harde schijf staan, die je niet ook op een ander browser tab open kunt hebben? Bankzaken, medische gegevens, je passwordmanager. etc etc Het komt allemaal eerst via je browser, voordat het op je harde schijf komt. Dus beperkt risico ben ik het niet zo mee eens.

[CorbataGames]

De passwords kun je uit een webpagina halen, daarvoor is toegang tot de password manager nodig en die is er niet. En webpagina's displayen dat ook niet in de source code (en anders is dat weer een heel ander probleem).

En je moet dat maar allemaal net open hebben staan op het moment dat je op die verkeerde link klikt.

Laten we het er dan wel over eens zijn dat het risico beperkter is dan toegang tot je harde schijf....

[Keypunchie]

e kunt gewoon personal data via een website/browser uitlezen en je zegt dan dat er geen direct risico is... hoezo zie je dat als bedrijf niet als een zeer groot risico?

Omdat je *browser* deze informatie deelt uiteindelijk...

Technisch gesproken is ook het bestandssysteem een lek. De browser kan bij data, en die dan uploaden naar een malicieuze pagina.

Daarom hebben browsers niet de mogelijkheid om zomaar het hele filesysteem te doorlopen aangezet, maar zul je via een dialoogje een specifieke permissie moeten vragen en bestand actief uploaden.

Dit is op een bepaalde manier vergelijkbaar: Javascript is in principe een drama: je laat iedere willekeurige webpagina namelijk *code* uitvoeren op jouw systeem. Dat moet je afschermen, op zoveel mogelijk niveaus. Zoals Apple @johnbetonschaar aangeeft: browsers kunnen prima timing-attacks ondervangen.

[Reactie gewijzigd door Keypunchie op 30 januari 2025 12:00]

[SunnieNL]

Als apple aangeeft dat ze dat prima kunnen ondervangen.. waarom praten we dan over dit probleem en waarom duurt het zo lang voordat Apple met een fix komt?

Overigens heeft het proces geen toegang tot het bestandssysteem zover ik in de artikelen kan vinden. Ze openen een 2de tab om data in de cache van de processor te krijgen om die dan dwars door alle beveiliging heen (of geen beveiliging) uit te lezen.

[Keypunchie]

heb je de PDF gelezen: https://predictors.fail/files/FLOP.pdf ?

Het is net ff minder makkelijk (en accuraat!) dan "linkje laten klikken". Chrome konden ze al niet kraken, alleen Safari.

Academisch is het een interessante hack. Praktisch is het vooral een uitdaging voor browsermakers en geeft het de noodzaak voor "defense-in-depth" aan. Of het nou echt een praktisch groot lek is? Deze moeite doen als je mensen ook gewoon direct kunt phishen...

[SunnieNL]

Leuk dat het niet met Chrome te reproduceren is....
Maar wat is de meest gebruikte default browser op Apple devices waar deze chips in zitten?

Ik vind op zich dat je het probleem net als Apple baggatilseert.
Wat als ik weet dat het bedrijf waar jij werkt een bepaalde passwordmanager heeft.
Zo'n password manager heeft standaard wel een web interface, die al geactiveerd is omdat de plugin die de wachtwoorden injecteerd al actief is (je bent immers al aan het werkt).

Dan kan ik via deze hack dus ook data uit die passwordmanager stelen.

Dat je defense in depth moet hebben wil nog niet zeggen dat je het probleem als eigenaar van de browser en de chips als een kleiner risico kan zien. Daarnaast is dit Apple. De fabrikant die alle hardware en software bij zichzelf houdt en alles zelf in de hand heeft.

Stil dit was Microsoft geweest die het probleem had in Edge en het voort kwam op een Intel of AMD chip. Dan was ik ook niet weggekomen met "ja maar het is alleen in Edge, bij Chrome heb je het probleem al niet... en daarnaast moet je ook nog maar net een intel of amd chip hebben"

Vergeet ook niet dat de onderliggende engine van Safari in heel het OS gebruikt wordt in andere taken, die mogelijk net zo vatbaar zijn voor het probleem.

[Keypunchie]

Heb je de PDF gelezen? Password manager maak ik me het minste zorgen over.

Hier is een wachtwoord dat kan worden gepakt. En om sportief te zijn doe ik mijn tweakers login passwd.
QfRvbK2MfM9BFrTa

Maar, als je de PDF leest, dan zie je dat de gekopieerde data niet perfect is (dit omdat het niet daadwerkelijk de buffer uitleest, maar op basis van timing statistische waarschijnlijkheid bepaald).

In bovenstaande password zijn ws. 1-4 karakters incorrect. Ik vertel je niet of het zo is en ook niet welke. Success!

[Reactie gewijzigd door Keypunchie op 30 januari 2025 14:45]

[SunnieNL]

Fijn dat je voornamelijk vanuit jezelf denkt. Je hoeft de PDF niet te lezen om te zien dat de gekopieerde data niet perfect is, dat is ook al in het plaatje te zien van de demo.
Maar er zijn hele groepen mensen die niet zulke wachtwoorden gebruiken als jij doet en er iets hebben staan als AppleIsGreat!

En ja, ik heb de PDF gelezen. Echter het feit blijft dat er persoonlijke informatie verzameld kan worden en dat op zich niet heel erg lastig is om te doen. Dat is een dataleak van persoonlijke informatie die veroorzaakt wordt door Safari op een hele reeks aan apple devices die door miljoenen mensen gebruikt wordt. Daarnaast maakt het een spear phishing aanval mogelijk op bedrijven.

Om maar een paar quotes te doen van hun eigen website en het originele artikel van Bleeping computers:

Real-world implications
The FLOP and SLAP attacks are significant due to their impact on modern and widely used hardware and because they can be executed remotely without requiring physical access.
A victim would just need to visit a malicious website for the secrets to leak, bypassing browser sandboxing, ASLR, and traditional memory protections.

en

Why are SLAP and FLOP Significant?
There are hardware and software measures to ensure that two open webpages are isolated from each other, preventing one of them form (maliciously) reading the other's contents. SLAP and FLOP break these protections, allowing attacker pages to read sensitive login-protected data from target webpages. In our work, we show that this data ranges from location history to credit card information.

Maar he.. het ontwijken van browser sandbox, ASLR en memory protections en het zijn van een remote execution... hoe gevaarlijk kan dat nou zijn, behalve het feit dat je al een hele lading aan defense-in-depth van het OS omzeilt. Bedoel, het gebeurd alleen in Safari, die bij grootste deel van de mensen de default browser is op het type devices waa we over praten en gelukkig maken meerdere onderdelen van het OS gebruik van diezelfde engine.

Ze geven ook in de paper aan dat het fixen een combinatie is van software en hardware. De eerste fix in Safari had Apple al lang door kunnen voeren.

We gaan zien hoe snel dit in het wild wordt misbruikt nu alle informatie op tafel ligt. Maar ik vind dat Apple het aardig downplayed.

[Reactie gewijzigd door SunnieNL op 30 januari 2025 17:30]

[laptopleon]

Hadden we jaren geleden ook niet vergelijkbare toestanden met Spectre en nog eentje? Ook met preemptive multitasking situaties, als ik me goed herinner, alleen dan met hele generaties chips van Intel. Daar werden toen ook softwarematig voorzieningen uitgezet, waardoor dat niet meer kon gebeuren en ook toen werd je computer daar wat langzamer van.

Alleen heb ik in al die jaren nooit ook maar één slachtoffer langs zien komen in het nieuws. Nou staat niet iedereen te trappelen om zoiets publiek te maken, maar als het op zo’n schaal speelde – het moet toch om minimaal tientallen miljoenen computers hebben gegaan – en lang niet al die computers zullen op korte termijn gepatched zijn, dus je zou dan toch slachtoffers moeten hebben gehad, als het allemaal zo serieus was. En zeker een deel zou schadevergoedingen hebben geëist, desnoods via de rechter. Of zijn die zaken er wel geweest en heb iets gemist?

[VBald]

Je hebt helemaal gelijk. Jeetje, ik hoop dat ze snel met een fix komen, want ze verkopen aardig wat van deze chips! Moet je nagaan dat vorig jaar M4 is uitgekomen en M4 Ultra nog moet uitkomen voor de Mac Studio. Het maakt M1 MacBook toch aantrekkelijker om te kopen.

[SunnieNL]

Ik vermoed dat de oplossing is om via software/cpu firmware upgrade bepaalde zaken uit te schakelen. Dit soort predictions zijn vaak hardwarematig en niet zomaar via software aan te passen behalve dan het uitschakelen van bepaalde functies. Resultaat is vaak dat de CPU trager wordt (hebben we bij intel en amd ook gezien) wat weer impact heeft op de hele ervaring. Dus dat zal vast meespelen.

[VBald]

Het moet wel via een firmware, maar ik hoop eigenlijk meer dat Apple de architecture wat aanpast, want ze hebben de alles zelf in hand en kunnen de veranderingen doorsturen naar de chipmakers. Maar dat gaat zeker wel tijd kosten en ze moeten dat eigenlijk wel doen vanwege M4 Ultra. Het is niet slim om een Flagship chip uit te brengen wetend dat er kwetsbaarheden in zitten.

[Plofkotje]

Een M1 chip lost dit ook niet op, dan heb je weer last van deze vulnerabilities in hardware: https://gofetch.fail/

Wat dat betreft heeft de hele CPU markt last van dit soort vulnerabilties in CPU ontwerpen.

[VBald]

Ik ben het met je 100% eens, wist niet dat M1 ook zwaktes had, dank je!

[GertMenkel]

Gelukkig kun je SLAP tegengaan door gewoon een andere browser dan Safari te pakken. FLOP is lastiger, omdat dat ook andere browser treft.

Ik ben benieuwd of Apple de kwetsbaarheden bagatelliseert om dezelfde reden dat Intel en AMD er zo lang over deden om met patches uit te komen, namelijk dat de oplossing een significante performance-impact heeft.

[densoN]

In één van de documenten wordt afgesloten met:

The paper identifies an impactful vulnerability in sev
eral widely used processors. It rigorously reverse en
gineers and documents the data speculation technique
that these vulnerable processors use, and it develops
practical exploitation techniques showing how to ex
ploit the vulnerability.

Ik was in de veronderstelling dat Apple de kwetsbaarheid wegwuift, omdat de aanval dermate complex is, dat de kans op misbruik zeer beperkt is. Mogelijk dat deze publicatie daar verandering in gaat brengen en Apple ook tot een ander besluit komt.

[zjorsie]

De aanval kan op afstand uitgevoerd worden via een browser, waarin een malafide webpagina geladen wordt. Als gebruikers naar zo'n pagina gelokt worden, is het voor aanvallers mogelijk om gevoelige data te stelen via andere tabbladen. Het gaat dan bijvoorbeeld om events in de iCloud Calendar, locatiegeschiedenis uit Google Maps en inboxcontent uit Proton Mail.

Gevoelige informatie uitlezen vanaf een malafide site via een browsertab is niet best. Dit betekent dus ook dat je passwordvault kan worden uitgelezen.

"Op basis van onze analyse zijn wij van mening dat dit probleem geen direct risico vormt voor onze gebruikers", zegt Apple.

Ik denk dat ze bedoelen "Dit probleem oplossen betekent een herdesign van onze CPU's en/of het omruilen van apparaten moeten omwisselen en dat is veel te moeilijk/duur".

Rare reactie. Je betaalt de Apple premium om dan alsnog met een systeem te zitten waarop via het bezoeken van een malafide site gegevens op je PC gecompromised kunnen worden.

Zou dit betekenen dat ze dit niet kunnen oplossen d.m.v. een firmware patch zoals Microsoft heeft gedaan tegen Spectre e.a.?

[Reactie gewijzigd door zjorsie op 30 januari 2025 11:46]

[Eren]

Speculative-executiefunctie. Deze functie, die in sommige chips zit, stelt CPU’s in staat om alvast bepaalde berekeningen uit te voeren, nog voordat ze nodig zijn. Als ze dit uitzetten, is het probleem wel verholpen, maar is je apparaat niet meer zo snel. Alleen vraag ik me af hoeveel trager het zou worden.

Ik heb nu een M3 Pro. Wel een mooi apparaat, maar nu denk ik ook 2500 euro en dan heb ik een machine waarbij mijn data gemakkelijk gestolen kan worden door alleen naar een website te gaan. Misschien kan een adblocker de malafide code al blokkeren, geen idee.

[pumpidumpi]

Er moeten nogal wat dingetjes op zijn plek vallen (voorwaarden) voordat de attack succesvol is (iig de FLOP, de andere heb ik niet bekeken). Dus ik denk eerder dat de kans dat aan die voorwaarden voldaan wordt zodanig klein is (of misschien in de praktijk niet voor komt?) dat ze daarom zeggen dat het wel meevalt.

However, as we were not able to train the LVP across userspace / kernel boundary, to successfully exploit the LVP in a kernel environment, an attacker must find three types of gadgets: training gadgets containing loops of ≤32-bit loads, converter gadgets causing the wrong load value to access a secret, and finally leak gadgets to exfiltrate the secret over covert channels. We leave the task of creating tools for finding such gadgets, as well as creating realistic LVP kernel exploits, to future work.

[zjorsie]

Als ze dit uitzetten, is het probleem wel verholpen, maar is je apparaat niet meer zo snel.

Dat zou ik ook verwachten, en ik snap dat ze dat willen voorkomen, maar ik heb liever een (iets) trager systeem dan een systeem waarbij ik kans heb dat bijv. mijn wachtwoorden lekken.

Er moeten nogal wat dingetjes op zijn plek vallen ...

Ja dat klopt, maar dat kan je toch niet accepteren? Een systeem wat al bewezen informatie 'kan' lekken is gewoon niet veilig en moet gefixt worden. Als het niet gefixt wordt is het wachten op malware die de kans op misbruik vergroot.

[densoN]

Twee quotes uit de papers:

We emphasize
the need for novel hardware and software countermeasures
against LAPs in future work.

First, we suggest increasing the randomization entropy
for types and memory allocations in Safari, as the lack thereof
allowed us to create a fake string header and heap-spray the
underlying string data7. Then for Chrome, we suggest caging
the WebAssembly structs in a memory region, similarly to
what it already does with JavaScript objects.

Het zal dus een combinatie zijn van hard- en software maatregelen. In sommige gevallen zijn aanwezige beveiligingsmaatregelen niet toegepast, mogelijk i.v.m. impact op performance. Dat is niet heel ongebruikelijk, maar ik zou het als afnemer wel prettig vinden als ik de keuze krijg om performance te verruilen voor (verbeterde) security.

[Keypunchie]

Specifiek voor passwords maak ik me niet eens zo zorgen als je de PDF leest.

de titel van een afspraak "Confidential meeting" werd iets als "Confieental meeuing".

Dit omdat het een statistische aanval is: op basis van timing schatten ze de waarde in de buffer.

Van een random 16 character-password zullen ze minstens 1tje verkeerd hebben....maar zonder dat ze weten welke of hoeveel. Daar wordt de search space niet bepaald kleiner van.

[DevWouter]

De zoekruimte wordt eigenlijk heel erg klein als je uitgaat dat maar 1 teken van een onjuist is.

Een wachtwoord van 16 tekens (alleen lowercase A-Z) heeft 26¹⁶ mogelijkheden. Echter als je weet dat er maar 1 teken onjuist is dan wordt het 26*16=416 mogelijkheden.

[Keypunchie]

Dat is dan ook niet het scenario, gelukkig maar!

[laptopleon]

Dan nog laat bijvoorbeeld een bank je maar een paar keer proberen in te loggen. Bij de echt gevaarlijke zaken wordt binnen een paar procent van die 416 mogelijkheden je poging / pas al geblokkeerd, als je al een wachtwoord van alleen onderkast letters mag gebruiken, want het juist bijna altijd verplicht een mix te gebruiken, met ook nog speciale tekens en cijfers. Dan gaan we er nog van uit dat er geen mfa gebruikt wordt, wat bij banken etc intussen al jaren de norm is.

[bartje]

Deze functie, die in sommige chips zit, stelt cpu's in staat om alvast bepaalde berekeningen uit te voeren, nog voor ze nodig zijn. Cpu's worden daarmee sneller

Maar betekent dat niet dat dit ook meer stroom dus accu capaciteit kost?

[VBald]

Ja je hebt gelijk, misschien is de fix heel simpel, namelijk deze functie uitzetten, dan bespaar je stroom en duurt het wat langer voordat je antwoord hebt. CPU's worden er niet sneller, denk ik, maar je workflow is sneller, want er is iets van te voren al geladen voordat je er gebruik van maakt, dus denk bv dat een site met links en dat die links al voor geladen zijn, zoiets.

[Admiral Freebee]

De CPU wordt er wel sneller van want je kan beter gebruik maken van de beschikbare resources omdat je niet moet wachten op de uitkomst van een evaluatie. Als de voorspelling juist was dan kan je direct verder met de uitvoering van de code en heeft de CPU niet moeten wachten op nieuwe data en instructies. Dat kan namelijk vrij lang duren.

Speculative execution is een belangrijke factor in de snelheid van moderne CPU's. Het zomaar uitschakelen zou serieuze gevolgen hebben op de prestaties.

[VBald]

Volgens mij zeggen wij hetzelfde. Ik denk dat "Cpu's worden daarmee sneller" verkeerd omschreven is?? Want de snelheid van een CPU is in GHz als een CPU sneller wordt gezegd dat de GHz hoger wordt en dat klopt niet, want de CPU hebben een max GHz.
Het is dat het antwoord al klaar staat en je sneller verder kan met je werk. Het uitschakelen zorgt er dus mogelijk voor dat je langer moet wachten op je antwoord omdat de nieuwe data en instructie nog niet gegeven zijn, dus een impact om prestaties en moet je langer wachten op antwoord.

[sabas123]

Dit soort sub-componenten zijn vaak extreem klein en gebruiken niet al te veel stroom. Persoonlijk gok ik dat omdat je sneller je computatie kan doen, je ook sneller weer terug in idle state komt waar je meer stroom bespaart dan dat het kost.

Echter zijn dit van die dingen dat je eigenlijk niet kan vast stellen zonder empirisch te meten.

[darknessblade]

Ik vraag me af of deze kwetsbaarheid ook gebruikt kan worden om "UNOFFICIAL" SSD's te pairen met de mac, zonder de nood voor een 2e mac

[berchtold]

Heb je het artikel wel gelezen? Dit gaat niet over data op je schijf. Laat staan ssd’s

[Source90]

De kwestsbaarheid zit dus wel in de Iphone 15 Pro (Apple A17 Pro chip) en niet in de normale Iphone 15 (Apple A16 Bionic chip)?

[DLSS]

Ik weet niet of ze die wel getest hebben 🤔