'Google vertraagt Android-beveiligingsupdates en dat geeft aanvallers kansen'

Google stelt beveiligingsupdates voor Android met drie tot vier maanden uit en dat geeft aanvallers de kans om lekken te misbruiken. Dat beweren de makers van GrapheneOS. Fabrikanten van smartphones krijgen info over de lekken.

Door die vertraging hebben fabrikanten de tijd om updates voor al hun telefoons te maken en te testen. Voorheen gebeurde het maandelijks, maar Google is vrijwel geheel overgegaan op patches elk kwartaal uitbrengen, zegt GrapheneOS, een van de bekendste op privacy gerichte custom roms voor Android. "De patches worden breed verspreid onder fabrikanten, waartoe de meeste engineers toegang hebben."

Die patches staan onder embargo, maar vinden toch hun weg naar bedrijven als NSO, die deze kunnen gebruiken voor hun tools om toegang te krijgen tot versleutelde smartphones. Die periode van embargo was eerst een maand en is nu dus vier maanden. Daardoor krijgen veel meer telefoons tegelijk de patches. "Dit brengt de beveiliging van Android in gevaar om oem's een beter imago te geven door de lat lager te leggen." GrapheneOS wil eromheen gaan werken door met releases te gaan werken waaruit externe ontwikkelaars de patches zouden kunnen destilleren.

Reacties (51)

[Chiwn]

Ik begrijp niet zo goed wat het beoogde doel van Google hier is. Ik begrijp uit de post van GrapheneOS zelf wel dat het om bezuinigingen zou gaan, maar ik weet ook dat zij over het algemeen vrij cynisch tegenover Google staan. Met het idee de patches onder embargo te zetten en dan fabrikanten langer de tijd geven, is dan het idee dat de security patches overal tegelijk uitgerold worden, ipv op sommige telefoons eerder dan anders?

Waarschijnlijk heeft het er ook mee te maken dat ik niet goed begrijp hoe GrapheneOS nu aan de patches komt. Ontvangen zij die ook van het Android team van Google direct en dan onder embargo, net als andere fabrikanten? Uit hun blogpost begrijp ik ook dat ze die extern willen publiceren, en dan dat iemand anders ze reverse engineered en teruglevert aan GrapheneOS zodat ze er eerder in kunnen. Hoe breekt dat niet het embargo dan?


Als iemand antwoord heeft op een van deze vele vragen, hoor ik het graag :)

[Kenhas]

Komen patches niet terecht in het AOSP project ? Als dat zo is, zijn de patches ook open source en kan er dus gekeken welk probleem die patch specifiek oplost om zo te weten te komen waar de exploit juist zit.

Ik neem aan dat GrapheneOS wordt opgebouwd vanuit AOSP.

Maar totaal niet gebaseerd op kennis ter zaken. Kan dus verkeerd zijn

[Finraziel]

Ik ben ook niet gehinderd door enige kennis, maar als iets onder embargo staat dan kan het niet tegelijk ook al open source beschikbaar zijn natuurlijk. Beetje raar als de medewerkers van die bedrijven niks mogen zeggen terwijl iedereen het gewoon in AOSP op zou kunnen zoeken.

[Kenhas]

Volgens mij worden exploits en toekomstige patches wel al gedeeld met fabrikanten zodat ze zich kunnen voorbereiden. Dan duurt het nog zijn tijd eer alles in AOSP terecht komt.

Maar op één of andere manier geraakt die informatie wel al tot bij "partijen met minder goede bedoelingen".

Als de patches vroeger in AOSP zouden komen, voor de fabrikanten klaar zijn, kan er simpel terug gekeken worden

[wiseger]

Graphene ontvangt geen patches. Ze distilleren die zelf uit reeds gedane releases van andere Android releases of moeten wachten op code commits in AOSP.

Graphene is helemaal geen klant van Google. Zij ontvangen dus ook geen patches.

[sambalbaj]

Ik zat ik nog aan de systeemupdates via Google Play te denken.

Dat zijn ook beveiligingsupdates ook voor toestellen die vaak al jaren niet meer ondersteund worden door de fabrikant. Waarschijnlijk niet volledig en sowieso geen features maar wel iets.

Alleen nooit begrepen waarom je die echt handmatig moet triggeren en er geen instelling is om dat automatisch te doen. Veel mensen kennen dit niet eens.

Daar staat ook altijd de maand van update bij en het was me al opgevallen dat dat niet meer maandelijks is, maar een wat langere periode. Inderdaad zo'n 3 maanden wat aansluit bij dit verhaal over per kwartaal.

[Theratron]

Toch is er iets raars met die beveiligingsupdates van Google. Ik heb hier nog een Note 9 van Samsung liggen (beste telefoon ooit!), maar die krijgt echt geen updates van Google meer, die stopten op het moment dat Samsung het toestel ook niet meer ondersteunde. En dat was al na 3 jaar.

Ik had inderdaad verwacht dat de updates van Google langer door zouden gaan, maar dat is in ieder geval bij de Note 9 niet het geval helaas.

[Chiwn]

Ik heb het mastodon draadje nog eens opnieuw gelezen en begrijp nu dat ze oproepen aan engineers bij OEMs om te lekken, met de aanname dat dit naar aanvallers (zoals NSO) toch ook al wel gebeurd.

Daarna hebben ze het over een alternatief waarbij lekken niet nodig zou zijn, maar dat het te reversen valt uit complete releases waar de patch al wel in zit, maar dat de losse patches zelf niet toegestaan zijn voor die 4 maanden oid? Ik volg daar het verhaal niet meer goed, omdat ik niet begrijp hoe ze dan wel aan de releases zouden komen waar de patch in ingebakken zit, en ook niet waarom er dan een hele omweg met externe GrapheneOS devs nodig is om de source weer aan GrapheneOS terug te voeden.

[wiseger]

Graphene heeft geen overeenkomst met Google, sterker nog, hun unique selling point is dat ze een Google vrije Android leveren.

Alleen heeft Graphene geen grote ontwikkelgemeenschap die zelf security patches ontwikkelen, ze liften stiekem toch mee met Google en haar partners. Dus pakken ze security releases van Google en haar OEM's om vanuit daar de patches te distilleren om die vervolgens ook zelf te implementeren en te releasen.

Kennelijk zijn ze niet blij met de vertraging die daarbij optreed dus willen ze graag in een eerder stadium van Google en haar OEM's leren met welke patches die bezig zijn in plaats van afhankelijk te zijn van officiële releases.

[Matthijs8]

Graphene heeft via samenwerking met een OEM toegang tot deze patches. Maar er zit 4 maanden embargo op, dus ze mogen deze patches niet releasen met sourcecode.
En het gekke is dat er geen embargo op binary packages zit. Die mogen ze dus wel releasen, maar de sourcecode mogen ze pas 4 maanden later openbaar maken. En vanuit die binary packages is de sourcecode gemakkelijk te achterhalen, waardoor dat hele embargo een heel raar idee is.

[satya]

Geen idee. Op mijn Pixel krijg ik maandelijks OS en security updates aangeboden. Andere fabrikanten, vaak met een eigen schil hebben de nodige tijd nodig om die voor hun eigen toestellen te implementeren, ook als het de upgrade naar android 16 betreft waar ik al drie maanden op draai.

[desalniettemin]

Ik ook. Vorige week nog de nieuwe Android 16 deel 2 update/upgrade gedownload en geinstalleerd.

[Loller1]

Google geeft maandelijks beveiligingsupdates uit aan OEMs, dus waar gaat het hier specifiek eigenlijk over? Stellen ze bepaalde fixes uit tot 3 maanden nadat het gefixed is?

[Reactie gewijzigd door Loller1 op 8 september 2025 12:18]

[wiseger]

Het gaat hier om Graphene. Die zijn geen OEM van Android. Die gebruiken AOSP als basis van hun OS.

Graphene is dus afhankelijk van de security releases die ze Google en haar OEM's zien doen in de praktijk. Dat is hun basis om patches te maken voor GrapheneOS.

Dus pas wanneer stock Android en de OEM varianten hun patches releasen, kunnen zij eraan beginnen voor GrapheneOS.

[Loller1]

Graphene heeft toegang tot de OEM packages.

[wiseger]

Heb je ook een bron die bevestigd dat ze officiële toegang hebben? Ik kan dat namelijk nergens vinden.

[CH4OS]

Deze Tweet, van henzelf, overigens, bevestigd dat zij early access hebben op patches voordat de patches naar AOSP gaan: https://x.com/GrapheneOS/status/1964754118653952027

CC: @wiseger

[Reactie gewijzigd door CH4OS op 8 september 2025 12:45]

[wiseger]

Dat weet ik, maar is dat officiële toegang of krijgen ze die toegespeeld van derden?

Zelf zeggen ze:

GrapheneOS can only fully provide security updates to a device provided that the OEM is releasing them.

[CH4OS]

Zie de eerste zin van de Tweet:

We have early access to Android Security Bulletin patches and will be able to set up a workflow where we can have releases already built and tested prior to the embargo ending.

Dus voor Android hebben ze de (vroege) toegang tot de Android Security Bulletin patches, maar niet tot de implementaties van de (apparaten van de) OEMs.

[Reactie gewijzigd door CH4OS op 8 september 2025 12:55]

[wiseger]

Het gaat me erom dat het niet officieel van Google is. Er is een officiële Google OEM die ze de toegang geeft:

GrapheneOS has a partnership with a Google OEM, granting them access to the security patches before they are publicly released to the Android Security Bulletin.

[CH4OS]

Met OEM word(t)(en) dan ook de fabrikant(en) van telefoontoestellen bedoelt, dat hoeft ook niet per se Google te zijn (aangezien ze zelf ook Pixel telefoons maken). Maar een Samsung, LG, Sony, OnePlus, Xiaomi et cetera.

[wiseger]

Precies, dus Graphene heeft zelf geen overeenkomst met Google, ze zijn geen OEM partner.

Om toch vroege toegang tot de security bulletins van Google te krijgen, werken ze dus samen met een onbekende derde partij. Die onbekende derde partij heeft wel een OEM overeenkomst met Google.

[GertMenkel]

Volgens de draad van GrapheneOS zijn de patches al wel klaar, maar zijn die onder embargo tot alle fabrikanten de tijd hebben gehad om hun spul te patchen. Er zijn bijvoorbeeld patches voor december dit jaar die al uit zijn (en in theorie mogen fabrikanten die patches ook al uitleveren), maar pas in december kunnen die geopenbaard worden.

De conclusie is dus dat de updates die iedere maand worden geopenbaard niet per se updates zijn die men de maand ervoor heeft ontwikkeld. Je hebt wel maandelijkse releases, maar de maandelijkse release bevat niet alle patches.

[CH4OS]

Google geeft maandelijks beveiligingsupdates uit aan OEMs, dus waar gaat het hier specifiek eigenlijk over? Stellen ze bepaalde fixes uit tot 3 maanden nadat het gefixed is?

Het embargo waarover gesproken wordt, is het embargo op het praten over het lek, niet over de (code) aanpassing om het op te lossen. De fix moet dus al live staan voordat een en ander publiekelijk bekend wordt, om verder misbruik van het lek te voorkomen.

[Gwaihir]

Ik moest het een aantal keer lezen! Als ik het goed begrijp:

Google deelt behoorlijk breed informatie over beveiligingsproblemen in Android welke open staan en nog enkele maanden open blijven staan.

Aangezien deze informatie, onbedoeld maar onvermijdelijk, ook beschikbaar staat voor de beter georganiseerde aanvallende partijen, is Android hierdoor erg makkelijk te hacken.

Dit probleem was in het verleden kleiner omdat sneller gepatcht werd.

[wiseger]

Nee dat is niet correct. Je moet onderscheid maken tussen de betaalde Android van Google die afgenomen wordt door veel telefoon leveranciers en de open source varianten die geen klant van Google zijn.

Google brengt zelf de patches uit op stock Android en levert ze aan haar partners die ze dan zelf releasen naar hun klanten.

GrapheneOS is geen partner van Google, ze gebruiken het AOSP.

[jpsch]

Als je drie kleine patches gaat vervangen door een grote, is de kans toch ook groter dat er nieuwe problemen ontstaan, doordat ze elkaar kunnen beïnvloeden?

[Baserk]

Recente Android based telefoons lopen dus gemiddeld 2 maanden achter op de data beschikbaar bij bijv. Israëlische NSO, omdat van Alcatel tm ZTE, medewerkers patch info vanuit Google/Android ontvangen, en dit voor een interessante pensioenbijdrage aan NSO&Co kunnen lekken?

De gemiddelde martel-dictatuur loopt dus zo'n 2 maanden voor, op de patches die Android-telefoon gebruikers kunnen verwachten?

Fraai zeg. 'Don't be evil...'

[Reactie gewijzigd door Baserk op 8 september 2025 14:29]

[wiseger]

Dat geldt voor elk bedrijf dat security patches ontwikkeld. Er zit altijd een tijd tussen het ontdekken van een kwetsbaarheid en het uitbrengen van een patch voor die kwetsbaarheid.

Als in die periode uitlekt dat de kwetsbaarheid bestaat, dan kan een derde partij zoals NSO daar gebruik van maken.

Ik zou niet weten hoe Google dit anders zou moeten doen? Ja ze zouden kunnen kiezen voor het Apple model, dus het eco systeem gesloten maken zodat de hele wereld alleen nog stock Android kan gebruiken maar dan komen de open source varianten zwaar in de problemen.

[theduke1989]

ik heb me niet meer zo verdiept in de laatste jaren betreft patches voor telefoons.
maar sinds wanneer doet google dit om het kwartaal en waarom?

Denken ze dat er geen lekken zijn in hun systemen, vinden ze het minder belangrijk geworden?
wat speelt hier achter?

[pete4live]

Zoals in het artikel staat is dat waarschijnlijk om fabrikanten langer de tijd te geven om aan updates voor hun eigen toestellen te werken. Volgens mij was dit wil aangekondigd, alleen nu trekken de makers van GrapheOS aan de bel omdat dit dus ook mogelijk beveiligingsrisico's oplevert.

[escalate]

Ik denk in eerste instantie dat dit meer gestandaardiseerd overkomt, er zijn altijd veel op en aanmerkingen over de update cycle van android smartphones met betrekking to beveiliging en support. Ik kan mij voorstellen dat ze dit doen om een andere imago op te stellen meer in een homogene release cycle over alle telefoon makers. Dit gaat echter wel ten koste van echte beveiliging een embargo periode op beveiliging updates is ook een beetje raar als je er over nadenkt, helemaal als je het breed verspreid over een grote groep mensen.

Als je een Alu-hoedje op doet zou je ook nog een link kunnen leggen met MoW van Amerika en hun intelligentie apparaat. Hoe dan ook we zien meer en meer overheden zich buigen over cyber security op allerlei manieren, en niet altijd ten behoeve van de individu maar over het geheel. Dit gaat soms gepaard met geplande beveiliging risico's zoals backdoors of master key voor data extractie, zie de UK en EU. Je kunt er vanuit allerlei hoeken naar kijken en voor alles is een goed punt te bedenken.

[watercoolertje]

Lang leven het Apple-model waar ze pas releasen als het op alles werkt ipv zo snel mogelijk. Dat werkt bij Apple nog redelijk omdat er weinig toestellen zijn. Maar totaal niet op Android.

Snap niet waarom het op elkaar moet lijken, de oude manier werkte dus beter voor Android en dat heb ik ook altijd geroepen als reactie op mensen die vinden dat het allemaal tegelijk moet want dat is 'beter'. Alleen klinkt het vooral beter maar is de praktijk dus slechter.

[Reactie gewijzigd door watercoolertje op 8 september 2025 10:27]

[TheVivaldi]

Volgens mij is dit meer vergelijkbaar met Microsoft, die normaliter alleen beveiligingsupdates op Patch Tuesday uitbrengt.

[DdeM]

Eigenlijk juist niet. Zoals ze het deden was het vergelijkbaar met Microsoft, elke maand updates behalve als ze echt een kritiek lek dichten, dan in de vorm van een "out-of-band" patch, maar nu worden updates dus maanden vertraagt (ik hoop de "out-of-band" patches niet).

[TheVivaldi]

Ik bedoelde meer in de zin van dat ze een vast moment prikken, net als Microsoft doet, en niet bij Apple “waar ze pas releasen als het op alles werkt”, zoals de persoon boven mij schreef. In die zin een vergelijkbaar concept: op een vast moment beveiligingsupdates uitbrengen.

[Loller1]

Niet echt, Microsoft communiceert met niemand over de beveiligingspatches die ze gaan uitbrengen totdat het daadwerkelijk beschikbaar is. Google doet dat hier dus wel al maanden op voorhand.

[wiseger]

Microsoft levert dan ook geen Windows aan derde partijen die het naar eigen inzicht aan mogen passen. Windows is uniform en wordt door Microsoft zelf onderhouden. Dus kan Microsoft gewoon elke maand onaangekondigd (in de zin van wat erin zal gaan zitten) een security patch release uitbrengen.

Google levert wel OEM Android en moet haar OEM leveranciers op de hoogte houden wat er in de planning zit zodat die tijdig erop kunnen acteren. Op die manier is de tijd tussen het releasen van security patches op stock Android en OEM Android versies ze kort mogelijk.

[GertMenkel]

De oude manier bracht ook risico's met zich mee. Als Samsung op het punt staat om een nieuwe Android-versie te shippen, hebben ze niet per se de tijd om nog snel even een CVE-fix te cherrypicken/mergen zonder de release te vertragen. De tijd die nodig is om patches te mergen is ook een van de redenen dat fabrikanten vaak maanden achterliepen op Google qua beveiligingsupdates.

Zodra het eerste toestel gepatcht was op de oude manier, was er meteen een groot risico voor andere toestellen. Een hacker kan eenvoudig kijken wat er veranderd is tussen twee releases en daar een exploit mee ontwikkelen. Zolang niemand nog misbruik maakt van de kwetsbaarheid, kan het daarom verstandig zijn tijdelijk de patch achter te houden totdat in een keer bijna alle apparaten kunnen worden gepatcht.

Bij de eerste SPECTRE-aanval zag je zoiets ook bij Linux gebeuren, waar ontwikkelaars van grote Linux-distrobuties lange tijd patches ontwikkelden en klaar hadden gezet zodat op het moment dat de exploit wereldwijd werd aangekondigd, iedereen veilig kon zijn, en niemand extra risico zou lopen doordat iemand besloten had zijn eigen gebruikers een vroege patch uit te delen.

Het is een afweging tussen snel je eigen spul fixen en de klanten van je partnerbedrijven niet met extra risico op te schepen. Ik ben het persoonlijk oneens met hoe lang ze hun deadlines laten uitlopen, maar het is niet per se incorrect om niet direct alles aan de grote klok te hangen.

[Reactie gewijzigd door GertMenkel op 8 september 2025 11:34]

[zalazar]

Het update design van Android is helemaal verkeerd.
Dat fabrikanten hier zo veel werk aan hebben is niet goed.
Misschien wordt het eens tijd dat Linux op de telefoon meer aandacht krijgt.

[wiseger]

Want? Google onderhoud stock Android en brengt daar continue security updates voor uit.

De partners van Google ontvangen de stock Android security updates zo vroeg mogelijk zodat ook die regelmatig security updates uit kunnen brengen voor hun variant van Android.

Open source varianten zijn afhankelijk van wat ze andere bedrijven zien releasen. Die lopen dus per definitie een stuk achter.

[divvid]

dus... mooie kans voor de EU om fabrikanten te verplichten dan mensen AOSP op hun telefoon MOETEN kunnen zetten. Helaas is het hardware landschap dusdanig versplinterd dat drivers dan weer een probleem zijn. (Met open bootloaders heb je ook weer een beveiligingsgat, maar daar is vast wat op te verzinnen).

Zou wel een mooie use case zijn: creëer je gelijk een meer open markt met alternatieve spelers.

[wiseger]

En wie gaat AOSP dan onderhouden? Op dit moment is Google de partij die veruit de meeste code commits doet, maar als die daar mee stoppen, wie gaat het dan overnemen?

Bij een partij als Graphene werken minder dan 15 FTE. Die dragen niet zoveel bij aan AOSP.

Dat is nu het hele probleem met open source, je moet wel een community bij elkaar krijgen die samen gratis de ontwikkelingen blijft doen, die samen gratis het support blijven leveren. Als je die community niet hebt, dan kom je al snel in de problemen.

[divvid]

het is geen probleem als Google dat blijft doen. MS kan ook stoppen met Windows, RedHat kan ook stoppen met Linux en Apple kan het ook over een andere boeg gooien.

Waar het om gaat is dat de smartphone markt effectief een duopolie is waarbij één partij extreem homogeen is en de andere partij enorm gefragmenteerd is. Als consument kun je niet objectief kiezen of b.v. een Samsung 'beter' up to date is dan een Xiaomi of een Pixel, zeker niet als Google updates tegen houdt.

Al met al zou de consument er bij gebaad zijn als de boel open gegooid wordt.

[wiseger]

Waarom zou een commercieel bedrijf zijn eigendommen gratis willen doneren als open source?

Uiteraard is een consument er ook mee gebaat, als Tesla zijn FSD gratis beschikbaar zou stellen aan alle autofabrikanten.

Als ASML al zijn onderzoek resultaten, handleidingen en alle tips en trucs m.b.t. EUV lithography die ze in decennia ontwikkeld hebben nu gewoon eens met de hele wereld zouden delen, dan worden chips een stuk goedkoper. Daar zou de consument erg mee gebaat zijn.

[Reactie gewijzigd door wiseger op 8 september 2025 16:30]

[Alex3]

Voor patches in Windows ben je niet afhankelijk van de fabrikant, maar Google moest weer zo nodig het wiel opnieuw uitvinden.

[wiseger]

Google doet precies hetzelfde met stock Android als Microsoft doet met Windows. Installer je stock Android, dan krijg je op dezelfde manier je patches als met Windows.

Android wordt echter ook gebruikt door OEM's die er hun eigen sausje overheen doen. In dat geval krijg je de patches van de OEM.

En dan heb je nog de open source varianten. Die zijn afhankelijk van de community. Wanneer de community patches commit, dan kunnen de open source varianten de patches ook uitbrengen.

En dan heb je nog een uitzondering, de open source variant die samenwerkt met een OEM om op die manier security patches uit te kunnen brengen.

De keuze is aan de gebruiker.

[baseonth3road]

Alleen de mensen die nog de illusie hebben dat hun telefoon en data privaat is tegenover overheidsinstanties zien dit als een probleem.

[HollowGamer]

Daarnaast willen ze ook sideloaden gaan verbieden.

Als de EU wilt dat je externe app stores toelaat, dan is een heel eenvoudige stap om dan toch je marktaandeel te blijven behouden.

Zelfde ook met deze patches, maar ook features (ook voor privacy) worden achtergelaten. Terwijl GOS deze dus wel commit aan Google.

[wiseger]

Hoe kom je erbij dat Google side-loaden wil verbieden?

Google wil dat apps ondertekend zijn met een certificaat van een geregistreerde developer. Ze willen geen anonieme apps toestaan. Dat heeft weinig met side-laoden te maken.