Hackers konden code uitvoeren op Android-telefoons via kwaadwillig spraakbericht

Google heeft details vrijgegeven over een aanval waarmee hackers code konden uitvoeren op Android-telefoons en hogere rechten op deze toestellen konden krijgen. Dat was mogelijk door kwetsbaarheden in onder meer de Dolby-audiocodec te misbruiken.

Project Zero, de afdeling van Google die kwetsbaarheden in software onderzoekt, meldt in een blogpostserie dat Android-telefoons tot voor kort kwetsbaar waren voor een aanval waarbij geen gebruikersinteractie nodig was. Door een kwaadwillig spraakbericht te verzenden via Google Messages, konden aanvallers code in de Dolby-mediacodec uitvoeren. Vervolgens was het via een privilege escalation mogelijk om te 'ontsnappen' uit de mediacodec en code met kernelrechten uit te voeren.

Bij de aanval misbruikten de hackers twee bugs: de eerste, CVE-2025-54957, betreft een out-of-boundswritebug en bevindt zich in de Dolby Unified Decoder, die wordt gebruikt om Dolby-audioformaten te decoderen. De tweede, CVE-2025-36934, werd gevonden in een kerneldriver en maakte het mogelijk om hogere rechten op de telefoon te krijgen.

Transcriptie van spraakbericht

Volgens het team groeit het risico op dergelijke zeroclickexploits naarmate een telefoon meer AI-functies krijgt. Voor veel van deze functies wordt kunstmatige intelligentie gebruikt om content op de telefoon, zoals berichten, te analyseren voordat de gebruiker deze opent. In dit geval kon de kwetsbaarheid plaatsvinden omdat er AI wordt gebruikt om spraakberichten te transcriberen. Dat vereist dat deze berichten meteen na ontvangst al worden ontsleuteld en dus niet pas als de gebruiker ze beluistert.

Project Zero ontdekte de aanvalsmogelijkheid op de Pixel 9, maar het team denkt dat dit ook op andere Android-toestellen mogelijk was. Overigens biedt Google vanaf de Pixel 8 een beschermingsmaatregel die de privilege-escalationaanval zou verhinderen, maar deze werkt alleen als gebruikers de optie Geavanceerde bescherming activeren. Volgens Google is dezelfde aanval niet mogelijk op iPhones, omdat de Dolby Unified Decoder op deze toestellen een extra beveiliging bevat tegen out-of-boundswriteaanvallen. Project Zero roept Dolby op om deze beveiliging ook op andere platforms toe te voegen.

Het is niet duidelijk hoelang de telefoons kwetsbaar waren voor deze aanval. Project Zero stelde Dolby op 26 juni 2025 op de hoogte van de bug, maar Googles Pixel-team zou pas op 8 oktober patches hebben ontvangen om de bugs te dichten. Vervolgens duurde het nog tot 5 januari 2026 voordat dat team deze patches ook daadwerkelijk had toegepast. Samsung loste de kwetsbaarheid op 12 november als eerste Android-fabrikant op, schrijft Project Zero.

Reacties (13)

[beerse]

Mooi te zien hoe de ontwikkelaars en vooral de software architecten hier de rechten verkeerd gebruiken.

Als een applicatie bij bepaalde gegevens moet kunnen, dan moeten die gegevens van de juiste rechten worden voorzien. De applicatie moet altijd in haar eigen account blijven draaien. Dus ook de ai-applicaties hoeven geen admin/root/god rechten te krijgen. Dan kan de ai-applicatie alles doen wat ze moet doen met de gegevens maar ze kan daarmee nooit meer doen dan waar ze voor is gebakken.

Op het gemiddelde unix/linux systeem is dat heel goed uit te leggen, daar zou je zaken met service accounts en groepen netjes kunnen inrichten. Dan kunnen andere service accounts op groep basis lees rechten kunnen krijgen.

Onder android is dat praktisch het zelfde in te richten. Daar is een redelijke structuur aanwezig van applicaties en leveranciers. Elke nieuwe leverancier kan een eigen groep krijgen en de geïnstalleerde applicatie een eigen (service) account. De rechten op het filesysteem kunnen met de juiste instellingen zodanig worden ingericht dat nieuwe bestanden netjes van een bepaald account en groep worden en ook de lees en schrijf rechten netjes ingevuld.

[Webgnome]

Ja daar heb je een punt. Echter als ik het zo snel lees , en ook even de CVE's doorneem (vluchtig), gaat het er nu net om dat dat systeem dat die rechten moet waarborgen eerst helemaal word overspoeld met requests waardoor die, om het zomaar te zeggen, de kluts kwijt raakt. En daarna kun je gebruik maken van de out of bounds bug om code uit te voeren die je niet mag uitvoeren.

[beerse]

Dat zou in dit geval wel zo kunnen zijn. Waar het mij om gaat is dat het android systeem helaas niet zo is ingericht als ik het hier boven beschrijf. In ieder geval niet voor de in het artikel genoemde ai-tools. Daar begrijp ik dat die tools dus wel root-rechten hebben. Dat zouden die tools zeker nooit mogen krijgen. Overigens ook de dolby systemen niet.

Het is mijn idee dat het ooit wat losser is ingericht om niet te veel performance te missen. Toen, 15 as 20 jaar geleden, was dat nog een te accepteren idee. Tegenwoordig kan het allemaal best wel netjes. Helaas duurt het een tijdje voor dat dat allemaal ook echt is ingericht.

[Caelorum]

Dan zou ik het artikel nog eens lezen. De bug zat in de kernel en een audiocodec. AI wordt hier alleen genoemd, omdat voor bepaalde scenario's automatisch zonder tussenkomst van de gebruiker bij ontvangst de audiocodec wordt gebruikt om spraak naar tekst om te zetten.

De bug zit echter niet in de AI en die AI functionaliteit heeft ook niet teveel rechten. De bug zit in de codec waarna privilege escalation via een tweede bug in de kernel wordt getriggered.

[Reactie gewijzigd door Caelorum op 16 januari 2026 16:10]

[n00bje]

Het Android systeem is wél zo ingericht. Iedere app draait onder een unieke User ID en in een eigen sandbox.

[beerse]

Dat detail klopt wel zo ongeveer. Maar als ze meer rechten wenst, dan is het, zeker op oudere android versies, al snel dat ze ' alle' rechten krijgt en niet de minimale extra rechten. En zodra ze alle rechten heeft, dan kan ze ook alles.......

[blorf]

Probleem bij Android is dat de toestel-eigenaar geen root is en niks te vertellen heeft. Sommige apps hebben al meer rechten...
Waarschijnlijk, als er 1 smartphone bestond met UNIIX-permissies op alle bestanden. processen en apparaten en dat ook nog door telecomproviders wordt gesteund, gebruikte iedereen die. Er onstaat dan vanzelf een OS dat alles uit de hardware haalt en ook afdoende beveiligt.

[beerse]

De gebruiker is gebruiker van de software en heeft dus de rechten van de software die ze gebruikt. Daarmee heeft ze alle rechten van alle software gecombineerd. Overigens wel met gebruik van de software. Bij het gebruik van andere software dus andere rechten. Dat is wat de gewone gebruiker verwacht.

Helaas zijn veel super-gebruikers en wannabee hackers verwent met de manier waarop bij msWindows de rechten zijn gegroeid: Van iedereen kan en mag altijd alles naar Alles moet kunnen en lukt dat niet dan word ik administrator en kan ik toch alles. Dat terwijl msWindowsNT wel netjes rechten en plichten kan regelen en instellen.

De huidige stand van zaken is dat veel te veel software architecten een msWindows achtergrond hebben en daarmee de huidige systemen inrichten. Bedenk dat Android in de basis een linux kernel is en daarmee zeker de mogelijkheden heeft zoals linux en unix dat aankunnen.

Kijk naar hoe het op het apple platform werkt met iOS. Dat is gebaseerd op BSD, een echte Unix. Zelf heb ik geen detail zicht op hoe het daar is geregeld maar ik vermoed dat het daar iets meer met de unix geest is ingericht.

[blorf]

Sja, dat is een beetje mijn probleem. Hoezo niet de hardware? Daar is die gebruiker evengoed gebruiker van. Laten we vooral een commercieel ecosysteem dat voor zoveel mogelijk winst allerlei beperkingen afdwingt op een consumenten-computer als hoogste autoriteit beschouwen en niet de koper. Is je wel eens oppgevallen dat alle smartphones een ARM-processor hebben maar er geen enkele is die de eindgebruiker een ARM-compatible programma laat uitvoeren? Geen probleem

Blijkbaar is het mobiel zijn als fysieke kenmerk van deze computers reden om alles dicht te timmeren en de eindgebruiker te ontdoen van alle permissies....

[Reactie gewijzigd door blorf op 16 januari 2026 23:13]

[GertMenkel]

Overigens biedt Google vanaf de Pixel 8 een beschermingsmaatregel die de privilege-escalationaanval zou verhinderen, maar deze werkt alleen als gebruikers de optie Geavanceerde bescherming activeren.

Dat is inderdaad wat de onderzoekers zeggen:

Pixel 8 onwards shipped with MTE, but unfortunately, the feature has not been enabled except for users who opt into Advanced Protection mode, to the detriment of Pixel’s other users.

Echter zullen veel tweakers vermoedelijk advanced protection mode niet aanzetten omdat dat ook een enorme hoeveelheid data naar Google stuurt naast dat het een aantal security-features aanzet.

Gelukkig kun je MTE ook aanzetten zonder extra data met Google te delen middels de ontwikkelaarsopties). Op Android 16 kan dat door te gaan naar Instellingen -> Ontwikkelaarsopties -> Memory Tagging Extension -> MTE aanzetten totdat je dit uitzet. Je kunt MTE ook tijdelijk aanzetten (zodat als je telefoon/ROM crasht als je het aanzet, je na een reboot weer een functioneel apparaat hebt), of als je de instructies voor Android-ontwikkelaars volgt, ook per app kiezen of je deze extra bescherming wilt hebben.

In GrapheneOS (en mogelijk andere ROM's met beveiligingsfocus) staat MTE overigens standaard aan. Gebruik je GrapheneOS op je Pixel, dan was je nooit kwetsbaar voor deze aanval.

Standaard staat MTE uit omdat het een (kleine) performance-impact heeft. Apple heeft, zoals Google's onderzoekers ook zeggen, deze optie wel standaard aangezet ondanks de performancekosten. Vermoedelijk speelt mee dat Apple's chips gewoon veel sneller zijn dan wat Google in de Pixels stopt waardoor de impact een stuk minder voelbaar zal worden.

MTE doet het overigens ook op andere apparaten, niet alleen op de iPhone en Pixel. Je CPU moet daar ondersteuning voor hebben aangezien de beveiliging zich in hardware bevindt, Telefoons met de MediaTek Dimensity 9300 hebben bijvoorbeeld ook hardware-ondersteuning voor MTE, dus je kunt op apparaten die er gebruik van maken proberen of MTE stabiel werkt op je telefoon, de performance-impact bekijken, en kiezen of je daar gebruik van wilt maken.

Overigens is MTE lang geen eindoplossing voor geheugencorruptieaanvallen (de hardware van de Pixel 8 serie maakt bypasses mogelijk voor langdurige aanvallen, zoals in Javascript-browseraanvallen), maar het maakt het wel een stuk lastiger voor exploits om te werken.

[Looongcat]

Volgens het team groeit het risico op dergelijke zeroclickexploits naarmate een telefoon meer AI-functies krijgt. Voor veel van deze functies wordt kunstmatige intelligentie gebruikt om content op de telefoon, zoals berichten, te analyseren voordat de gebruiker deze opent.

Dit baart mij flinke zorgen. Met alle root-access gekkigheid die LLMs en dergelijke AI-modellen met zich meebrengen, is het nog steeds niet vanzelfsprekend dat dergelijke AI-modellen altijd sandboxed dienen te werken? Als er elk mogelijke input aan een model kan worden meegegeven, dan kan een ondeterministisch AI-model in theorie ook elk mogelijke output geven, waaronder output waar het apparaat vulnerable voor blijkt te zijn. Of het nu waarschijnlijk is of niet, dit zou genoeg reden moeten zijn om AI-modellen per definitie in een sandbox te draaien on-device. Vanuit een sandbox heb je tenminste een extra laag aan bescherming waarin je AI-output nog kunt valideren alvorens verder (blijkbaar kwetsbaar) te verwerken.

[sympa]

Het zou ook kunnen helpen als het attack surface wordt verkleind. Waarom stuur je berichten met een Dolby-codec?

Tijd om terug te gaan naar een basale lijst van mogelijkheden.

[mbbs1024]

Hoog tijd dat er wetgeving komt die ontwikkelaars verantwoordelijk maken voor de schade die door gatenkaas software aangericht wordt.
Ook in het onderwijs en boeken over software ontwikkeling zou er meer nadruk op moeten gelegd worden op het produceren van veilige software, en niet enkel de syntax van een programmeertaal.