Lekken maken roottoegang op Android 17 mogelijk door op link te klikken

Een beveiligingsbedrijf heeft een exploit getoond om met behulp van twee lekken Android 17 over te nemen en root te verkrijgen. De lekken zitten in de Linux-kernel en in de Firefox-browser. Beide lekken zijn inmiddels gedicht.

De IonStack-exploit maakt gebruik van GhostLock, een lek dat al vijftien jaar in elke Linux-kernel zit, beweert Nebula Security. De kwetsbaarheid bevindt zich sinds Linux 2.6.39 in de rtmutex. Ontwikkelaars hebben het lek in versie 7.1 gedicht. De exploit werkt door systeemcommando's in een vrijgekomen stuk geheugen te schrijven, waarna de kernel deze uitvoert en de aanvaller roottoegang geeft. Het werkt in 97 procent van de gevallen.

Voor toegang tot Android 17 maakt de exploit gebruik van een lek in de JavaScript-engine van Firefox voor Android tot versie 151.0.3. De precieze uitleg van het lek volgt later, maar het werkt in elk geval door de gebruiker op een link te laten klikken. Mozilla heeft het lek al gedicht en zette de fix begin juni online. Voor zover bekend is de exploit nog niet in het wild misbruikt.

Reacties (42)

[kozue]

Hoezo kan een lek in een JavaScript library, wat in userspace draait, toegang krijgen tot root?

[RobertMe]

Waarschijnlijk omdat browsers tegenwoordig zeer complexe applicaties zijn en zo ongeveer "een OS op zichzelf" zijn. Met zaken als JIT compilatie van javascript code (dus javascript code echt compileren), WASM / "assembly in de browser", WebGPU als soort van Vulkan / OpenGL / DirectX, WebSerial en WebUSB om rechtstreeks met USB hardware te babbelen, ....

Het is ook niet voor niks dat ChromeOS puur naar de browser boot en dat je hele "OS" is. Of verschillende TV platformen die 100% web based zijn (LGs WebOS, Samsungs Tizen) en dus effectief ook gelijk staan aan "het is puur een browser" (zonder adresbalk).

[closefuture]

Interessante hypothese maar het verhaal is veel simpeler; Er zijn 2 lekken, 1 in Firefox en 1 in de Linux kernel. Via het lek in Firefox kun je bij het lek in de kernel uitkomen. Voila; Root vanuit Firefox.

[kodak]

Op deze manier kan je alles wel op complexiteit afschuiven. Firefox is geen ChromeOS en heeft daardoor ook niet spontaan maar belangrijke kenmerken die het de 'complexiteit' geven die nodig is om een browser een 'OS op zichzelf' te noemen. En complexiteit in gebruikersland zorgt op zich niet spontaan voor een probleem dat er root rechten verkregen kunnen worden. Dat is ook waarom het artikel vermeld dat om het lek in de kernel te gebruiken er gebruik is gemaakt van een (dit) lek in de browser. Omdat het twee verschillende lekken zijn. Alleen het lek in de kernel geeft de hoge rechten. Het lek via de browser is vooral handig om dat makkelijker te kunnen proberen.

[hcQd]

Waarschijnlijk maakt dit lek het mogelijk willekeurige code uit te voeren, waarmee je dan gebruik kunt maken van het andere lek, Ghostlock, om rootrechten te verkrijgen.

[laurxp]

Firefox lek: escape van JS sandbox naar regulier user proces. Kernel lek: escalate van userspace naar root.

[ultimasnake]

Daarom heet het een lek, er druppelt iets uit een container waar het niet uit hoort te komen 😅

[kodak]

Dat lek geeft zelf geen toegang tot die hogere rechten. Het heeft daarom ook een lage score gekregen. Het probleem is zoals @hcQd stelt, dat het mogelijkheid geeft om het andere lek proberen te misbruiken.

[arjankoole]

NIet direct in 1 keer, maar als je daarna privilege escalation kan doen, ben je er. Daarom is het ook belangrijk om lekker te patches die alleen lokaal uitvoerbaar zijn.

[lenwar]

Omdat ieder root-proces in userspace draait? Verreweg de meeste besturingssystemen laten niet de root-user (of equivalent) niet ‘in’ kernel space dingen doen. (Hooguit specifieke calls die erop ontworpen zijn)

[cherrycoke]

Niet direct, userspace is alleen het lanceerplatform. De echte sprong gebeurt doordat een syscall-pad in de kernel kwetsbaar is.

[Kalief]

Voor toegang tot Android 17

Werkt dit alleen voor Android 17, of tot en met 17 of vanaf 17?

M.a.w. zijn lagere versies die geen updates meer krijgen net zo kwetsbaar hiervoor?

[Jerie]

T/m. Het local privilege escalation lek zit in Linux kernel 2.6.39 tot 7.1 (je mag uitgaan ook backported naar oudere supported kernels, en nee je Chinese IoT camera met Linux MIPS kernel gaat deze update niet krijgen).

Het remote code execution lek zit in Firefox t/m 151.0.3. Vanaf welke versie staat niet in artikel. Dat lek zal in SpiderMonkey zitten, en die wordt ook door Firefox forks en Thunderbird gebruikt. Overigens in Thunderbird niet door bij. Plain trxt default, anders simple HTML.

Samen is het een chain. De een zonder de ander heb je weinig aan als aanvaller. Er was onlangs wel een lek in KVM, die zou je hier ook nog mee kunnen chainen.

Overigens bovenstaande over versies staat kraakhelder in het artikel.

Die lokale kwetsbaarheid zal in allerlei software moeten worden opgelost. Van een switch met EdgeOS tot een WAP met Unifi OS. Ook hier waarschijnlijk weer crickets op oud unsupported spul, en Chinees spul zoals de Chinese 10 gbit switch die ik hier heb liggen (de Amerikaanse Ruckus/Brocade idem, maar die is ook ouder en unsupported).

[Reactie gewijzigd door Jerie op 9 juli 2026 20:25]

[CPM]

Een IoT camera klikt niet op een link. Grapje ik begrijp de situatie.

[Jerie]

Goed punt hoor, my bad, laten we ook kritisch op elkaar blijven. Die gebruikt ook geen SpiderMonkey van Firefox. Ik dacht in die specifieke context aan de local privilege exploit. Hij is hoe dan ook allang zo lek als een mandje. Het is prijsschieten. Wel nog interessant te vermelden dat je mogelijk MITM kunt doen op URLs om zo deze kwetsbaarheid te injecteren. Maar dan ligt een kwetsbaarheid op een oude Electron app eerder op de loer. Al mag je hopen dat IoT cams geen volledige browser bevatten.

[Sebastian1313]

Mijn camera heeft ook geen Firefox Engine draaien lokaal...

Geen grapje trouwens.

[Reactie gewijzigd door Sebastian1313 op 10 juli 2026 20:21]

[Delgul]

Zo te zien is het tot en met Android 17... in ieder geval voor de android kernel. Firefox weet ik niet. De combi is nodig voor de hack om te werken.

[telenut]

Hmm, ik zou het wel handig vinden om voor heel specifieke zaken tijdelijk root toegang te krijgen tot mijn Android Device...( addblock bijvoorbeeld, en voor de NFC tag emulator is het ook handig)

[Super_Fred]

Dus: it's not a bug, but a feature?

[bzzzt]

Het vervelende is dat in dit geval niet alleen jij, maar ook anderen toegang krijgen tot je Android device...

[telenut]

Dat is inderdaad een stuk minder gewenst :-)

[swhnld]

Android 17 kwam 16 juni officieel uit, het Firefox lek was begin juni al gedicht, dus ik vermoed dat het lek al eerder bekend was vanwege de ontwikkeltijd. Maakte het dan niet een Android 17 Beta lek in plaats van een Android 17 lek? En is dat niet waarom je test voordat je iets uitbrengt, om de fouten te vinden?

[R.G]

Stel je hebt een android Telefoon lager Dan android 17? Werkt dit Dan ook of is dit alleen voor android 17 specifiek?


Dus Telefoon met end of support updates alleen nog security updates

[Jerie]

Heb even snel gezocht: 2.6.39 is blijkbaar uit 2011. Dat zou inhouden dat alle kernels van ongeveer 2011 t/m ergens vorige maand kwetsbaar is voor dit lek (ik zeg het expres ruim). Alle supported kernels zullen een patch moeten hebben gekregen (is veel en veel meer dan enkel 7.1). Dat zul je nog met PoC moeten verifiëren. Want het kan al gepatched zijn. Zo draai ik momenteel Firefox 152 op deze device met Android 15. Dat is ook niet moeilijk. De local priv esc is aan $vendor om die fix toe te passen, maar die fix is niet ingewikkeld.

Zoals ik elders al zei: wil je een smartphone pwnen zet deze dan paar maandjes in kooi van Faraday en hang hem vervolgens aan een updated UFED (of doe het handmatig, of met ander spul).

[R.G]

Heb je een simpele sneller manier om tijdeijk even ota updates van de fabrikant te blocken? zonder dat ik mijn werk apparatuur blok dus geen router blok maar echt op het device zelf. ( terwijl je geen root bent)

[Jerie]

VPN maken met router (inclusief killswitch) en in router de update URLs blokkeren via DNS blackhole en firewall rules. Welke dat zijn is vast her en der te vinden.

Lukt dat niet, radios uit, behalve WLAN. Verbind toestel met MiFi en voer het trucje aldaar uit (sommige MiFi draaien OpenWrt). Alle andere WLAN automatisch verbinden uit. Verwijder eventueel de creds.

Maar of dit zeker weten werkt kun je niet met zekerheid zeggen. Ben je forensisch bezig dan kun je dit risico niet nemen.

[Reactie gewijzigd door Jerie op 10 juli 2026 01:21]

[swhnld]

Artikel zegt specifiek Android 17, niets over oudere versies.

Op basis van de omschrijving verwacht ik dat het risico ook in oudere modellen zit, immers is er een kernel probleem, maar die benader je alleen in combinatie met in dit geval een lek in Firefox.

De vraag is dan nog, is er iets veranderd in de architectuur van Android 17 die het voor deze combinatie mogelijk maakte, of had Firefox een aparte build gemaakt voor Android 17 die dit lek mogelijk maakte. Het artikel is daar niet duidelijk over.

[R.G]

Ja klopt maar zie jerrie reactie

[Jerie]

Het artikel waar naar gerefereerd wordt is daar enorm duidelijk over. @arnoudwokke vermeldt diverse details, en de bron kun je e.e.a. verifiëren: https://nebusec.ai/research/ionstack-part-2/

Het is daarnaast een CTF. Een wedstrijd om via een gat in de Linux kernel root te krijgen. De kortste chain wint (dus een remote privilege escalation) wint. Regels staan hier: https://google.github.io/...arch/kernelctf/rules.html

Wat betreft Android 17:

This instance uses the latest LTS with COS kernel config and unpriviledged user namespaces turned off since July 1st, 2025. Besides that, io_uring and nftables are also disabled. Only the first submission is eligible per LTS kernel version, but we are upgrading the kernel version every 2-4 weeks on average.

Bekijk je de twee kwetsbaarheden afzonderlijk dan heeft het niets met Android 17 te maken.

[chrome moral]

Bug? Of feature?

[FrostHex]

De IonStack-exploit maakt gebruik van GhostLock, een lek dat al vijftien jaar in elke Linux-kernel zit, beweert Nebula Security

Bewijst maar weer eens dat Open Source helemaal niet zo veel veiliger dan Closed Source is….

[catfish]

Ik vraag mij zelf af of het niet omgekeerd is.
Dergelijke software is zo complex dat er maar weinig zijn die er mee bezig zijn en de code doorgronden. Het gevolg is dat dergelijke bugs niet snel gevonden worden.
Een door landen gefinancierde hackers groep heeft echter de middelen om actief op zoek te gaan naar dergelijke bugs in de code. Dat lijkt mij toch een stuk complexer bij closed source.
Hopelijk kan AI helpen, hoewel dat misschien net het omgekeerde effect heeft (AI zal het wel nakijken op fouten).

[Jerie]

Het bewijst niets, statistiek kan wel e.e.a. bewijzen maar n=1 of n=2 (beide projecten FOSS) is te weinig. Dat is categorie onderbuikgevoel.

Met IDA Pro en Ghidra worden lekken ook al sinds jaar en dag gevonden. Neem je bijvoorbeeld Java dan is daar nauwelijks iets aan te decompileren, Javascript idem. In C (de programmeertaal in kwestie) ga je dit vroeg of laat fout doen, en LLMs kunnen dit in sommige gevallen sneller opsporen dan een handvol pentesters. Maar het tegenovergestelde is ook waar. Er worden zat lekken gevonden door pentesters die LLMs niet vinden. Je hoeft ook geen goede pentester te zijn om lekken te vinden, en als je al iets vindt is men al tevreden. Je rapport en aanbevelingen moeten degelijk zijn. Ook dat is niet moeilijk, maar kost wel moeite. En dan gaat het om alles dat je niet vindt, maar wel had kunnen vinden. Daar zit hem het verschil tussen een pentester die het geld waard is, of niet. Ook in custom software of setups handmatig kwetsbaarheden proberen te vinden is zeer waardevol, en eigenlijk ook het leukste gedeelte van dit werk.

[R.G]

Ben jij een pentestee of security architect? Je hebt veel kennis lijkt

[Jerie]

Onderdeel van mijn opleiding geweest, ja, en voorheen ook in die branche gewerkt. Maar een goeie? Er zijn betere

[Advanced03]

Jammer dat het al gepatcht is, dit zou een mooie kans zijn geweest om root te krijgen op BL locked telefoons/tablets.

[Jerie]

Wat je zou kunnen doen is niet updaten. Doe je device drie maanden offline, en er is geheid een local kwetsbaarheid gevonden. Als ze dan ook nog een beetje traag zijn met patchen heb je zo twee a drie maanden extra tijd. Dat tikt aan.

[Knutselmaaster]

Betekent dit dat ik hoop mag hebben dat ik mijn poco met hyperos 3 (Android 15) binnenkort zonder gedoe en wachttijden kan rooten?

[Niema]

Lijkt het wel op idd

[Mister Duckles]

Klopt het dat je er tegenaan loopt dat hij in die community app aangeeft "quota reached"?

Zo ja, dan heb ik een manier die veel beter werkt!

Ik heb eerder dit jaar voor mijn Poco f3 op hyperos 1 bootloader unlocked met de hulp van xda forum & claude. Hieronder een linkje naar mijn pdf van de stappen (samengevat door claude) van wat ik heb gedaan. (Laten bijwerken voor hyperos 3)

https://drive.google.com/file/d/1qWzaioKWbngqewCZ_IhBe7cYLwl5AwEb/view?usp=drivesdk

Veel succes 🙂

[Knutselmaaster]

Hartelijk dank voor het vriendelijke delen van je document.

Met alle respect, ik hoop nu juist dat al die stappen en wachttijden niet meer nodig zullen zijn dankzij de bug uit het artikel; als in "Gooi de benodigde bestanden in de telefoon, Klik op een knop, leun achterover met een koud biertje terwijl alles vanzelf gebeurt, geniet van de geroote telefoon".

Ik heb in het verleden vaak mijn telefoons geroot, het wordt steeds lastiger en tijdrovender. Daar heb ik met mijn huidig dagelijks leven geen tijd meer voor. Vroegah was het een fluitje van een cent en binnen een uurtje zat je op een custom rom. (/Me wordt oud). Het zou leuk zijn als dit nu (tijdelijk) weer mogelijk wordt.

[PaulHelper]

In de reacties staat het al een beetje maar Android 17 bevat lek, lijkt aan te geven alsof alleen die versie het bevat. Wat ik lees lijkt het meer alsof android met die Firefox de lekken mogelijk maakt.

Als dat het geval is zou ik een andere titel - 17 neerzetten.