Onderzoeker: Android-fabrikanten wachten te lang met patchen van kwetsbaarheden

Een onderzoeker van Google Project Zero meent dat hackers gebruik blijven maken van oude kwetsbaarheden in Android omdat fabrikanten te lang wachten met patchen. De man verwijst naar een patch voor een kwetsbaarheid in een veelgebruikte Mali-gpu die nog niet is doorgevoerd.

Project Zero-medewerker Ian Beer verwijst in een blogpost naar vijf verschillende kwetsbaarheden in de Mali-gpu-driver van Arm die begin dit jaar zijn ontdekt. Dankzij een combinatie van deze kwetsbaarheden in de gpu-driver is een kwaadwillige hacker in staat om volledige toegang te krijgen tot het Android-besturingssysteem en bijbehorende gebruikersdata. Deze kwetsbaarheden zijn volgens Beer gemeld aan chipontwikkelaar Arm en die heeft afgelopen zomer dan ook fixes uitgebracht. Sommige van die fixes zijn volgens de onderzoeker echter ontoereikend of veroorzaken nieuwe bugs.

Beer stelt ook vast dat de patches in heel wat gevallen niet worden doorgevoerd door fabrikanten van Android-toestellen. Hierdoor blijven hackers gebruikmaken van oudere kwetsbaarheden zonder dat ze de noodzaak voelen om nieuwe kwetsbaarheden op te zoeken. De man roept fabrikanten van zowel chips als Android-toestellen op om patches voor kwetsbaarheden zo snel mogelijk door te voeren.

Reacties (81)

[CAPSLOCK2000]

Die fabrikanten moet inderdaad beter hun best doen maar het hele Android model is ook wel een beetje onhandig opgezet omdat er wederzijdse afhankelijkheden zijn tussen Google en de fabrikanten en de hardware waardoor ieder apparaat uniek is en apart moet worden ondersteunt.

Als ieder apparaat appart ondersteunt en getest moet worden dan zijn kosten voor (security fixes) dus hoog. Hoe duurder het is hoe minder bedrijven het zullen doen.

Het zou beter zijn als we een model krijgen dat meer op de PC lijkt waarbij er zoveel mogelijk gebruik wordt gemaakt van algemene drivers en interfaces. Daardoor hebben we een breed scala aan hardware waarop we verschillende OS'en kunnen installeren zonder dat het bedrijf dat de onderdelen geassembleerd heeft er iets mee te maken heeft.

[Xantilyst2]

Je ziet tegenwoordig fabrikanten ook 'stunten' met 3/4 jaar software ondersteuning/sec. patches, maar de vraag is wat de kwaliteit daarvan is? Als je dit bericht nu zo lees staat het leuk op papier tov de concurrent (lees: Apple), maar de praktijk zegt wellicht anders..

[LurkZ]

Is het bij Apple echt beter?
Ik kan mij Tweakersnieuws herinneren dat een heel ander beeld geeft.
Een bug is al >jaar gelden door een researcher aangemeld bij Apple.
Eerst totaal negeren. Dan een jaar later 'ondekt' Apple een bug die na een paar weken gefixt is.

Dus het fixen gaat vrij snel. Maar het erkennen van de bug zeer traag.
Per saldo heeft de gebruiker ruim een jaar met die bug rondgelopen.

[DutchKevv]

De 'bug' waarbij je in Safari de volledige history / passwords kon binnen harken door alleen met javascript een download request te doen naar de goede private directories was ook een leuke ..

Via Ajax doorsturen en daarna openen als sql DB.. volledige encryptie zeggen ze.... Mooi niet dus, want alles was plain tekst

Heeft 6 maanden ofzo gekost en puur omdat t public ging...

Grappig bedrijf

[Reactie gewijzigd door DutchKevv op 23 juli 2024 03:54]

[willemblans]

Ja maar dat was geen eng lek

[willemblans]

Waarom denk je dat . allemaal iPhones gebruiken

[Frame164]

Heb je wel eens de complete TR lijst van grote softwarepakketten gezien? Alle fixes moeten worden ingepland. En vulnerabilities die weliswaar geexploiteerd kunnen worden maar waar je heel veel voor moet doen zullen een lagere prio krijgen dan zaken die veel makkelijker schade kunnen veroorzaken.

[m_snel]

Beetje kort door de bocht natuurlijk, krijg al decennia om de paar maanden een update, soms zelfs vaker.
Maar het is natuurlijk makkelijker als je maar zes modellen hoeft te updaten.

[Shark.Bait]

Als je er voor het gemak vanuit gaat dat beide inherent hetzelfde zijn qua bugs en het uitbrengen van fixes, dan valt het bij android slechter uit omdat na het fixen van een bug Apple deze update doorvoert, terwijl de android fabrikanten in gebreke blijven nadat Google de bux gepatched heeft.

De bug waar jij het over hebt kan puur PR zijn; het lukte ze maanden niet hem fatsoenlijk te patchen, en dan op die manier ineens 'vinden' en meteen patchen. Je zou onderhand moeten weten dat aankondigingen van Amerikaanse bedrijven met een korreltje zout genomen moet worden.

[gabba25]

Blijf het ook heel bijzonder vinden dat PC's van 10 jaar oud nog steeds de laatste patches krijgen maar op smartphones blijft het gewoon dweilen met de kraan open. Als er nu eens naar iOS wat concurrentie was voor Android...

[sympa]

PC's van 10 jaar oud hebben vast ook lekken in drivers. Het OS krijgt een patch, de drivers niet altijd.

[The Zep Man]

PC's van 10 jaar oud hebben vast ook lekken in drivers. Het OS krijgt een patch, de drivers niet altijd.

Onder Linux krijg ik gewoon kernel en driver updates voor systemen van ~15 jaar oud.

[sympa]

Op ne nVidia driver niet meer. Maar als je iets mainstream open source hebt, dan wel.

[m_snel]

Je kan natuurlijk gewoon die van MS gebruiken, misschien iets minder snel of zonder toeters en bellen.

[El_Bartholomew]

Die 3/4 jaar slaat absoluut nergens op als die patch/update enkel 1 x per jaar wordt doorgevoerd en je de rest van de tijd kwetsbaar bent.

Heb al hele discussies met de bank gehad over hun app dat ik geen banking app wilde installeren en die mij probeerden te overtuigen dat dit echt wel veilig was.

Heb zo een collega die vorig jaar al geld op zijn rekening zag verdwijnen en zijn rekening had geblokkeerd.
Men had er niet aan gedacht zijn banking app te blokkeren en zo verdween de rest van het geld die nacht.

Blijkbaar hadden ze de banking app kunnen kopiëren en activeren in Duitsland op een ander systeem.

Ze hadden eerst geld eraf gehaald. Dan een groter bedrag er terug op gezet en dat zo een paar keer gedaan verspreid over een paar weken zodat de transacties niet door het bank systeem opvielen.
Als je je rekening niet dagelijks controleert omdat je er van uit gaat dat het veilig is ...

[josttie]

Ik neem aan dat je collega dan gewoon in ouderwetse phishing of fraude is getrapt, je kan niet zomaar een app kopieren van de ene telefoon en ergens anders aanslingeren. Wat wellicht wel kan, is malafide apps toegang geven tot je smsjes zodat ze wellicht de inlog code konden onderscheppen (maar zelfs dat lijkt me al vergezocht, dan hebben ze alsnog meer gegevens nodig die je collega moet hebben doorgegeven).

Ik vertrouw mijn banking apps prima op mijn telefoon, ook krijg ik juist push berichten als er iets bij komt of vanaf gaat, dat lijkt mij voldoende om te zien of er ineens gekke bedragen over en weer gaan.

[m_snel]

Een bank die sms gebruikt kun je natuurlijk niet serieus nemen.
Maar dat is een andere discussie, verder denk ik dat je wel gelijk hebt.

[willemblans]

Klopt, en Samsung met zijn mooie praatjes, is ook een groot drama, en ook ś nachts data verbruik, ook als je alles uitzet, hoe kan dat

[Z80]

Probleem is dat de fabrikanten van de losse onderdelen alles in een grote kluis houden.
Firmware en drivers zijn niet beschikbaar voor eindgebruikers.
Hierdoor wordt het heel lastig om een kaal os te maken en daar losse drivers op te installeren.
Camera module van sony, wifi van intel, soc van ***. gsm module van ***.

[Wolfos]

Dat heb je met PC's ook, alleen is dat dankzij een beter drivermodel (losse modulaire drivers) geen enkel probleem. Als fabrikanten gewoon binaries konden leveren zouden ze daar vast geen moeite mee hebben. Alleen werkt dat binnen Android niet zo.

[Reactie gewijzigd door Wolfos op 23 juli 2024 03:54]

[Quitzcused]

Dat kunnen ze dus wel, maar vertikken ze gewoon

[blorf]

Dat werkt bij 'mobiele computers' helemaal niet. Als fabrikanten binaries konden leveren voor gestandaardiseerde systemen had Android helemaal geen bestaansrecht. Dan werd het een ARM-kernel met I/O-drivers. Kun je een monitor en toetsenbord aan je telefoon hangen en opstarten van USB.

[UPPERKEES]

Losse drivers klinkt ook weer een beetje de Windows manier. Ze zouden eigenlijk die drivers in de mainline kernel moeten aanbrengen. Maar goed, dat betekent dat de kwaliteit hoog moet zijn en dat het open-source moet zijn. Dat is natuurlijk weer te efficient voor deze wereld...

[Wolfos]

Dan word toch die kernel steeds zwaarder als je alle drivers erin wilt hebben? Lijkt me nou ook niet de beste oplossing.

[UPPERKEES]

Dat gaat anders nu ook al prima. Elk systeem kan ik zonder gedoe booten. En anders zijn daar wel oplossingen voor, zoals modules of targeted kernels met alleen de drivers die nodig zijn voor een bepaald systeem.

[GertMenkel]

Het zou beter zijn als we een model krijgen dat meer op de PC lijkt waarbij er zoveel mogelijk gebruik wordt gemaakt van algemene drivers en interfaces.

Dat is wat Android een tijdje terug dus al gedaan heeft. Het probleem blijft dat fabrikanten ervoor kiezen om hun veranderingen niet upstream terug te mergen in de Linux-kernel waardoor er geen rekening kan worden gehouden met de vage eisen van individuele drivers. De mensen die wel moeite steken in het bijhouden van de kernel gaan niet gokken welke APIs wel en niet aangepast kunnen worden zonder het spul van Qualcom/MediaTek/vingerafdrukscannerfabrikanten/noem maar op kapot te maken. De broncode die wel gepubliceerd wordt (want dat moet) voldoet vaak niet aan de kwaliteitseisen om opgenomen te worden in de echte kernel en vrijwilligers gaan niet zomaar voor niks de troep van miljardenbedrijven opruimen.

De interfaces van de meeste standaardhardware zit al achter een kernel/Android-facade. Helaas kiezen fabrikanten nog steeds om hun spul slecht te schrijven of gewoon nooit updates te maken.

Het onderliggende probleem is dat de (onderdelen)fabrikanten niet willen. Dat los je niet op door heel Android opnieuw in te richten. Windows heeft een mooi stabiele API, maar als je een driver schrijft die instabiele API's gebruikt die alleen op Windows 10 1504 draait, ga je zelfs met een Windows-achtige problemen krijgen. Het verschil is dat op andere platformen fabrikanten vaak wel het fatsoen hebben nieuwe drivers uit te brengen als een nieuwe Windows-versie problemen oplevert.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 03:54]

[Xander2]

Het onderliggende probleem is dat de (onderdelen)fabrikanten niet willen. Dat los je niet op door heel Android opnieuw in te richten.

Yup, het is een cowboyverhaal, de BSPs die sommigen leveren willen nog wel eens een compleet omgebouwde kerneltree zijn of een oude omgebouwde git tree waar ze stiekem de versie in veranderen om te voldoen aan de Androideisen.

De enige oplossing die ik zie is dat Google of een soort Android stichting gaat forceren om drivers door hen getekend te laten worden waardoor ze QA kunnen doen en direct de onderdelenfabrikanten confronteren.

[_JGC_]

Het probleem is niet eens de API, maar de ABI.
Hardwarefabrikanten leveren een binaire blob aan die zo in de kernel geladen worden. Alleen de fabrikant heeft de broncode.
Er hoeft maar 1 klein ding te veranderen in de kernel en de binary interface verandert waardoor de module niet meer te laden is. Gevolg: oude kernel en geen updates.

Ik merk het zelf bij servers die ik beheer voor een klant, die willen per se Crowdstrike op hun servers. Die werkt met binary modules. Loopt alleen steevast 1 of 2 releases achter waardoor ik permanent met een onveilige kernel zit vanwege een stuk beveiligingssoftware.

[GertMenkel]

De oplossing daarvoor is heel simpel, dan moet Google maar over stappen op de Fuchsia-kernel, of een andere kernel die niet onder GPL valt. Het Linux-kernelteam gaat hun werkwijze in elk geval niet aanpassen omdat een paar bedrijven proberen om proprietary spul te gebruiken met een open kernel. Vroeger was Nvidia hier een ster in, maar zelfs Nvidia heeft toegegeven en is aan het overstappen naar een open driver (voor bepaalde grafische kaarten).

Het blijft een fabrikantprobleem. De Samsungs, Google's, en Xiaomi's van de wereld zetten updates voor drivers niet op de prioriteitenlijst. Dat mogen ze doen, maar de verantwoordelijkheid om hun spul bij te houden ligt niet bij Google. Google doet haar best, maar fabrikanten blijven een businessmodel houden dat niet bij Android past (namelijk proprietary blobs).

Voor de ABI heeft Google al een heel stel maatregelen genomen. Het is ook verplicht sinds Android 8 om waar mogelijk de nieuwe, verbeterde HAL te gebruiken. Ook heeft Google met Treble een hele hoop vendor-spul verplaatst naar een losse API met een API/ABI die stabieler.

Overigens betekent een Android-update niet meteen een nieuwere kernel. Genoeg security-updates die niet eens kernel-updates meenemen omdat de fabrikant er geen zin in heeft of hun leveranciers niet genoeg betaald heeft om daar nog updates van te krijgen.

Google stopt zo veel mogelijk werk in abstractielagen over de vendors heen maar het probleem blijft nog steeds dat de fabrikanten weigeren mee te werken. De kernel-ABI zelf stabiel maken is simpelweg niet realistisch, dat gaat regelrecht tegen het principe van de Linux-kernel in. Laat ze maar naar Windows Phone overstappen als ze dat zo graag willen.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 03:54]

[SunnieNL]

Fabrikanten moeten er ook voor zorgen dat het device stabiel blijft draaien.
Security staat hoog, maar voor zo'n fabrikant is stabiliteit van je product nog hoger.
Als ik dan lees:

Sommige van die fixes zijn volgens de onderzoeker echter ontoereikend of veroorzaken nieuwe bugs.

dan snap ik 100% waarom die fabrikanten de patch niet doorvoeren.

De vraag is dus: heeft hij aan die fabrikanten gevraagd waarom deze specifieke patch niet is doorgevoerd in hun firmwares. Grote kans dat het antwoord is: wij hebben het getest, maar de fix zorgt ervoor dat het device te instabiel wordt en zijn in afwachting van ARM voor het leveren van een stabiele driver.

Ik vind het artikel en de onderzoeker nu een beetje te kort door de bocht gaan door niet te vragen aan de fabrikanten waarom het niet is doorgevoerd. Tijd, instabieliteit bij testen, etc.

[CAPSLOCK2000]

Ik vind de reden wel interessant maar niet belangrijk. Links of rechts om is de uitkomst dat het apparaat niet veilig is. Als fabrikanten niet tevreden zijn met een patch moeten ze maar betere afspraken maken met hun leveranciers of zelf een patch schrijven. Je kan dus zeggen "het is niet stabiel" maar ook "wij willen geen geld uitgeven om een stabiele patch te laten schrijven".

Die onderzoeker in kwestie is gewoon pissig dat hij veel werk heeft gedaan voor niks en doet daar melding over. Wat de reden daartoe is mag iemand anders uitzoeken, dat is niet het soort onderzoek dat hij doet.

Ik vind zijn waarschuwing overigens erg belangrijk. Onze industrie staat bol van de afspraken en beloftes die niet worden nageleefd. Op papier zijn ze allemaal zo veilig als de Nederlandsce Bank maar zodra je er een vinger in steekt blijft er weinig over van alle beloftes voor patches, fixes en onderhoud op lange termijn.

Deel van het probleem is dat er zo ontzettend veel partijen bij betrokken zijn die allemaal naar elkaar doorverwijzen. Als ze allemaal 90% wel doen en 10% niet dan heb je na een paar stappen (hardware, fimware, android, google(?), fabrikant, telecombedrijf) nog maar de helft over en ben je maanden (zo niet jaren) verder voor de patch bij de gebruiker op het toestel staat.

Mijn Linux systeem heeft fixes soms binnen 24 uur nadat ze ondekt zijn. Nu is dat misschien een beetje het andere eind van het spectrum en niet representatief voor een "dom" apparaat voor de "domme massa" maar het laat wel zien dat het anders kan.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 03:54]

[SunnieNL]

Maar jouw linux komt niet kant en klaar van een fabrikant af gok ik? Ik denk dat je die zelf hebt geïnstalleerd. Dus je bent ook OK als er een keer een update uitkomt met een instabiele driver.
Jij kiest er op dat moment bewust voor die update door te voeren en zal misschien ook een stap terug doen op het moment dat het niet stabiel is en voor lief nemen dat je dan beveiligingstechnisch maar iets minder kan?

Maar zou je dat ook OK vinden als je TV of telefoon om de haverklap opnieuw opstart omdat er en instabiele driver door de fabrikant is geleverd en de TV/telefoon fabrikant die zonder na te denken installeert omdat het een security probleem oplost? Jammer van de stabiliteit, wel veilig.

Microsoft had jaren lang last van bluescreen die voor 90% veroorzaakt werden door slechte drivers. Raad eens wie de mensen de schuld gaven als ze weer een bluescreen zagen? Microsoft, of degene die de driver had geleverd?

[CAPSLOCK2000]

Maar jouw linux komt niet kant en klaar van een fabrikant af gok ik?

Jawel, Debian SID.

Ik denk dat je die zelf hebt geïnstalleerd. Dus je bent ook OK als er een keer een update uitkomt met een instabiele driver.
Jij kiest er op dat moment bewust voor die update door te voeren en zal misschien ook een stap terug doen op het moment dat het niet stabiel is en voor lief nemen dat je dan beveiligingstechnisch maar iets minder kan?

Ja, daar ben ik ok mee. Maar in praktijk gebeurt het heel zelden dat er iets mis gaat. En ik leef echt op randje. Ik zeg niet dat iedereen dat moet doen, maar wel dat het veel beter kan.

Maar zou je dat ook OK vinden als je TV of telefoon om de haverklap opnieuw opstart omdat er en instabiele driver door de fabrikant is geleverd en de TV/telefoon fabrikant die zonder na te denken installeert omdat het een security probleem oplost? Jammer van de stabiliteit, wel veilig.

Dat moet geen "of" vraag zijn. Als je auto niet veilig is dan ga je er ook niet meer rijden. Natuurlijk is ergens een balans te vinden maar nu ligt die verkeerd want het duurt vaak veel te lang.

Maar mijn punt is dat in praktijk mijn systeem niet om de haverklap opnieuw opstart. Het zou zo kunnen zijn maar het is niet zo.

Microsoft had jaren lang last van bluescreen die voor 90% veroorzaakt werden door slechte drivers. Raad eens wie de mensen de schuld gaven als ze weer een bluescreen zagen? Microsoft, of degene die de driver had geleverd?

De reputatie van MS schoonhouden speelt geen rol in mijn overwegingen rond security. MS heeft voor zover ik weet nooit besloten om geen driverbugs meer op te lossen om zo de stabiliteit te verhogen. Misschien omdat hun reputatie op het gebied van security ook niet best was en ze inzagen dat je fouten nooit helemaal kan voorkomen en dat je dus maar beter goed kan zijn in het snel oplossen van fouten.
MS is (tegenwoordig) juist een van de organisaties die aandringt op snel patchen.

[SunnieNL]

Je reactie op het MS verhaal geeft precies aan wat ik probeer te vertellen. Mensen gaven MS de schuld terwijl het de driverfabrikant was die de boel instabiel maakt.
Ook je opmerking over de auto is niet praktisch. Want stel dat alle systemen in je auto telkens opnieuw opstarten omdat de fabrikant security van de software boven gebruiksgemak stelt, dan ga je dus ook niet meer rijden met die auto omdat die onbruikbaar is geworden.

Daar gaat het hier ook om. Als de vendor van de gpu drivers levert die ervoor zorgen dat de telefoon allerlei bugs krijgt waardoor die onbruikbaar wordt, kun jij wel zeggen dat die fabrikant van de telefoon sneller de driver moet updaten, maar die fabrikant heeft bruikbaarheid van het product hoger in het vaandel staan. Als je telefoon onbruikbaar wordt krijgt de fabrikant van de telefoon immers al het commentaar over zich heen. Als die dan zegt "ja, maar die telefoon is nu wel veiliger" dan wordt ik daar als consument niet echt vrolijker van. Een fabrikant levert een totaal product af en is daar in zijn geheel voor verantwoordelijk.

En begrijp mij niet verkeerd. Veiligheid is ook belangrijk. Zeker als het de persoon in gevaar kan brengen. Persoonsveiligheid gaat boven alles. Maar als er geen direct gevaar is voor een persoon en het product wordt onbruikbaar door een veiligheidsupdate, dan kan die laatste wat mij betreft wat langer achterwege blijven.

[Reactie gewijzigd door SunnieNL op 23 juli 2024 03:54]

[CAPSLOCK2000]

Je reactie op het MS verhaal geeft precies aan wat ik probeer te vertellen. Mensen gaven MS de schuld terwijl het de driverfabrikant was die de boel instabiel maakt.

So what? Wat heeft dat met veiligheid (of stabiliteit) te maken?
Het is misschien heel vervelend voor de PR van MS maar dat mag geen excuus zijn. MS zelf heeft dat nooit zo gezien ondanks dat ze inderdaad (ook) vaak onterecht de schuld krijgen. Het laat juist zien dat MS het belangrijk vindt om wel te patchen.

Ook je opmerking over de auto is niet praktisch. Want stel dat alle systemen in je auto telkens opnieuw opstarten omdat de fabrikant security van de software boven gebruiksgemak stelt, dan ga je dus ook niet meer rijden met die auto omdat die onbruikbaar is geworden.

Dat is een stroman, zo'n auto zou niet de weg op mogen, je valt een theoretische situatie aan.
Auto's zitten al vol software en die sotware krijgt updates. Misschien niet zo vaak als het zou moeten maar het gebeurt. Dat geeft in praktijk geen problemen. Ik lees nooit dat er een file staat omdat een softwareupdat is mislukt.

Daar gaat het hier ook om. Als de vendor van de gpu drivers levert die ervoor zorgen dat de telefoon allerlei bugs krijgt waardoor die onbruikbaar wordt, kun jij wel zeggen dat die fabrikant van de telefoon sneller de driver moet updaten, maar die fabrikant heeft bruikbaarheid van het product hoger in het vaandel staan.

Je kan ook zeggen dat de fabrikant dan betere afspraken moet maken met de gpu vendor.
Als een auto slechte remmen heeft dan roept de fabrikant ze terug naar de fabriek en stuurt de rekening naar de leverancier van de remmen.

Als je telefoon onbruikbaar wordt krijgt de fabrikant van de telefoon immers al het commentaar over zich heen. Als die dan zegt "ja, maar die telefoon is nu wel veiliger" dan wordt ik daar als consument niet echt vrolijker van. Een fabrikant levert een totaal product af en is daar in zijn geheel voor verantwoordelijk.

Correct, veiligheid hoort daar bij.

En begrijp mij niet verkeerd. Veiligheid is ook belangrijk. Zeker als het de persoon in gevaar kan brengen. Persoonsveiligheid gaat boven alles. Maar als er geen direct gevaar is voor een persoon en het product wordt onbruikbaar door een veiligheidsupdate, dan kan die laatste wat mij betreft wat langer achterwege blijven.

Als een product onbruikbaar wordt door een update dan is die update gewoon niet goed en moeten ze harder werken om een update te maken die wel goed is. Als ze dat zelf niet kunnen omdat ze afhankelijk zijn van een leverancier dan moeten ze maar betere afspraken maken met die leverancier.

Maar dat is helemaal niet het probleem waar het hier om gaat want in dit geval zijn er patches.
De leverancier heeft netjes gedaan wat nodig is en patches uitgebracht. Ik heb nog niet gehoord dat die patches niet goed genoeg zouden zijn en als dat wel zo is dan hebben ze nu maanden de tijd gehad om het te verbeteren. Er staat wel in het artikel dat die fixes soms nieuwe problemen veroorzaken maar niet dat die nieuwe problemen erger zijn dan de oude problemen.

Het zijn de telefoonfabrikanten die hier zitten te suffen. Ik heb er ook nog niet een horen uitleggen waarom ze die patches niet opnemen. Misschien is daar een hele goede reden voor maar dan moeten ze het uitleggen en aangeven wat ze er aan gaan doen.

[SunnieNL]

Het staat letterlijk in het artikel

Deze kwetsbaarheden zijn volgens Beer gemeld aan chipontwikkelaar Arm en die heeft afgelopen zomer dan ook fixes uitgebracht. Sommige van die fixes zijn volgens de onderzoeker echter ontoereikend of veroorzaken nieuwe bugs.

De vendor van de GPU is dus nog niet klaar. De onderzoeker kan nu wel zeggen dat de fabrikant van de telefoon eens moet opschieten, maar hij zegt zelf al dat de vendor van de gpu nog niet stabiele en goede drivers heeft afgeleverd. Hij valt dus nu de verkeerde personen aan.

[CAPSLOCK2000]

De vendor van de GPU is dus nog niet klaar. De onderzoeker kan nu wel zeggen dat de fabrikant van de telefoon eens moet opschieten, maar hij zegt zelf al dat de vendor van de gpu nog niet stabiele en goede drivers heeft afgeleverd. Hij valt dus nu de verkeerde personen aan.

Als de vendor slecht werk levert dan heeft die fabrikant de verkeerde vendor gekozen. Het doet er niet echt toe wie hier fout zit, het gaat er om dat het fout is. En het is altijd de laatste in de keten die verantwoordelijkheid draagt voor wat er voor komt. In de eerste plaats de winkel die telefoon verkoopt, de winkel stelt de leverancier verantwoordelijk en de leverancier stelt de fabrikant verantwoordelijk.

Je zou wel kunnen stellen dat de onderzoek de schuld neer zou moeten leggen bij de winkelier, maar niet dat de fabrikant van de telefoon niet verantwoordelijk is voor de door die fabrikant gekozen onderdelen. Dan had de fabrikant maar andere onderelen moeten kiezen (of het recht en de mogelijkheid om zelfs drivers te maken, als dat het probleem is).

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 03:54]

[SunnieNL]

Wie zegt dat de fabrikant die vendor al niet op de flikker heeft gegeven. Feit is: er is geen stabiele versie van de driver waarin het beveiligingsproblemen is opgelost.

Dan moet je als onderzoeker niet stellen dat het probleem is opgelost door de vendor van de gpu, dat is namelijk niet zo. En dan moet je ook niet stellen dat de fabrikant die niet goed werkende driver moet uitleveren aan zijn telefoons. Het is juist goed dat hij dat niet doet.

Jij zou immers ook niet een problematische driver in jouw Linux machine gaan gebruiken en die gewoon links laten liggen. En dan zou je ook op je achterpoten gaan staan als een onderzoeker dan zegt: die @CAPSLOCK2000 is slecht bezig. Het beveiligingsproblemen is al opgelost in deze niet stabiele driver, dus die had hij al lang kunnen installeren.

Het stellen dat het er niet toe doet wie er fout is gaat hier ook niet op. Het hele artikel gaat om een onderzoeker die zegt dat de fabrikant fout is. Dat is niet juist. De vendor is fout, want die heeft het probleem niet opgelost in een stabiele en goed werkende driver. De fabrikanten doen dan het enige wat juist is, die onstabiele driver niet implementeren.

[CAPSLOCK2000]

Wie zegt dat de fabrikant die vendor al niet op de flikker heeft gegeven. Feit is: er is geen stabiele versie van de driver waarin het beveiligingsproblemen is opgelost.

Om precies te zijn staat er dat "sommige" fixes niet goed. Maar de fixes die wel goed zijn worden blijkbaar ook niet geimplementeerd.

Wat de fabrikant allemaal tegen de vendor heeft gezegd kan mij niks schelen, daar heb ik niks aan. Praatjes vullen geen gaatjes. Ik heb ook geen persbericht gezien waarin een fabrikant waarschuwt dat ze onveilige software leveren omdat hun leverancier het heeft verprutst. Ook geen winstwaarschuwing van de leverancier omdat ze een boete krijgen voor het niet nakomen van hun verplichting om goede fixes te leveren. Dus constateer ik dat de afspraken te vrijblijvend zijn.

En dan moet je ook niet stellen dat de fabrikant die niet goed werkende driver moet uitleveren aan zijn telefoons.

Dat zeg ik niet, ik zeg dat de fabrikant moet zorgen dat er wél goed werkende drivers komen. Hoe die fabrikant door voor gaat zorgen is niet het probleem van de klant.

Jij zou immers ook niet een problematische driver in jouw Linux machine gaan gebruiken en die gewoon links laten liggen.

Ik draai juist Linux omdat die situatie niet snel voorkomt. Natuurlijk zijn er wel eens luie fabrikanten of slechte patches maar onder Linux nemen de distributies (de "fabrikanten") wel de verantwoordelijkheid op zich om zelf problemen op te lossen als dat nodig is en dat gaat over het algemeen vrij vlot, en je hebt als gebruiker de mogelijkheid om zelf toch een "slechte" patch te installeren (of te verbeteren) als je de fix belangrijker vindt dan de nieuwe bug. Dat is niet voor gewone gebruikers maar een professionele IT-afdeling kan dat prima aan.

Android is op Linux gebaseerd dus die fabrikanten zouden het ook moeten kunnen. Het is wel zo, zoals ik in mijn eerste post schreef, dat Android/ARM op een aantal punten minder handig is dan Linux/x86 waardoor het begrijpelijk is dat het soms wat stroef gaat. Maar dat maakt het nog niet acceptabel.

Nu is het ook onder Linux zo dat je soms afhankelijk bent van een een hardware-vendor die geen goede drivers levert en de community het ook niet kan oplossen. Maar daar kan ik rekening mee houden bij het kopen van hardware. Bij ieder onderdeel dat ik voor mijn PC koop denk ik daar over na. In de meeste gevallen zijn er maar een paar leveranciers die al jarenlang heel voorspelbaar zijn in hoe ze omgaan met drivers, informatie, broncode en suport. Mij lukt het prima om onderdelen te kiezen die goed ondersteunt worden, dan moet zo'n bedrijf dat ook kunnen en zeker vanuit hun onderhandelingspositie.

[Frame164]

Het maakt nogal wat uit of iemand met kennis van Linux snel zelf kan patchen of dat je een patch moet maken die je automatisch moeten kunnen uitrollen naar miljoenen gebruikers die allemaal andere configuraties hebben en die, als het mis gaat, niet zelf kunnen gaan troubleshooten.

De denkfout wordt op deze site wel vaker gemaakt. Er zit een wereld van verschil tussen een stukje gecompileerde code en een product dat naar de markt kan worden geleverd.

[CAPSLOCK2000]

Het maakt nogal wat uit of iemand met kennis van Linux snel zelf kan patchen of dat je een patch moet maken die je automatisch moeten kunnen uitrollen naar miljoenen gebruikers die allemaal andere configuraties hebben en die, als het mis gaat, niet zelf kunnen gaan troubleshooten.

Zeker, maar dat is een balans. Mijn voorbeeld is om te laten zien dat het ook anders kan. Ik had het overigens nog niet eens over patches die ik zelf toepas maar alleen over packages die mijn distributie levert. Dat is wel redelijk cutting edge en niet geschikt voor de grote massa. Dat kan omdat de achterliggende ontwikkelomgevingen in verregaande mate zijn geautomatiseerd.
Dat is geen unieke situatie maar heel gewoon in de tijd van devops & agile. Hardwarefabrikanten moeten daar maar van leren maar helaas is software-development typisch niet hun sterkste kant.

De denkfout wordt op deze site wel vaker gemaakt. Er zit een wereld van verschil tussen een stukje gecompileerde code en een product dat naar de markt kan worden geleverd.

En in de industrie wordt de denkfout gemaakt dat je software eenmalig schrijft en dat je dan klaar bent met je product en daar zijn de processen op ingericht. Ja, dan duurt het maanden om fixes door te voeren, zoals dit artikel laat zien. Ze moeten gaan snappen dat de software minstens zo belangrijk is als de hardware en dat ze daar gedurende lange tijd voor moeten zorgen.

[Splorky]

Het zou fijn zijn als Android zodanig opgezet wordt dat (security) patches geïnstalleerd kunnen worden zonder dat de hardwarefabrikant er tussen hoeft te zitten.

Zelfs os updates zouden per CPU/ram combinatie er wat mij betreft door geloodst kunnen worden. Als de fabrikant er geen heil meer in ziet en de hardware is compatible dan terug naar basis android, misschien wel met een drempel zoals dat alleen als developer mode aan staat om huis tuin en keuken gebruikers te beschermen

[Harrie_]

Ik meende dat Google een aantal jaar geleden op de roadmap had staan om een streep te trekken door al die custom uitvoeringen van Android. Het idee was dan dat in feite iedere Android-telefoon voorzien zou zijn van een soort stock Android-One installatie waar dan een (beperkte) schil van de Fabrikant overheen gelegd kon worden om e.e.a. vorm te geven of in de huisstijl van de fabrikant te maken en waarbij de fabrikant uiteraard zelf nog 'third party apps' (bloatware) mee kon leveren. Allemaal vanuit de gedachte dat het makkelijker wordt om updates naar gebruikers te pushen en niet langer afhankelijk te zijn van fabrikanten die dergelijke updates zelf moeten gaan verwerken in 'hun' Android versie.

Ik krijg hier echter niets meer over gevonden... Weet iemand hier daar meer over?

[SunnieNL]

Dat is het Android One project. Er zijn echter niet zo veel telefoons die daar op draaien.
Maar daar zou dit probleem niet in opgelost worden. Want de GPU driver komt niet uit de Google Store en is geen standaard onderdeel van Android. Dat is iets wat vanuit de kernel komt en die kun je alleen updaten via een firmware update. Android One zou daar dus niet kunnen helpen.

(een andere killing feature van Android One is dat de update op de achtergrond plaatsvind op een 2de partitie en de telefoon alleen hoeft te rebooten... wat mis ik dat nu ik naar een Samsung ben gegaan)

[Echron]

Ik denk dat dit in theorie zelf eenvoudig mogelijk moet kunnen zijn, nu al is de security package een apart deel van Android waar zowel mijn tablet als m'n smartphone soms updates voor krijgen maar die lopen nu nog altijd via de fabrikant.

Mogelijks zijn het problemen met compatibiliteit indien de fabrikant aanpassingen doet die het tegenhouden dit volledig mogelijk te maken. Het zou interessant zijn om te zien waar kwetsbaarheden zich net bevinden. Is dit in libraries die door Android zelf gebruikt worden (en waarvoor dus een patch geinstalleerd zou moeten kunnen worden zonder dat de fabrikant hier voor iets tussen zit)

[Anonymoussaurus]

Dat gebeurt gedeeltelijk, maar niet voor alle componenten. Daarbij wordt er gebruik gemaakt van Project Mainline (oftewel Google Play System updates): https://www.xda-developer...line-modules-explanation/

[swhnld]

Google heeft al eens wat gedaan om dat mogelijk te maken met Android one toestellen, maar buiten Nokia hebben bijna alle fabrikanten er toch voor gekozen om op basis van de source code hun eigen Android versies te ontwikkelen.
Android is daarmee een containerbegrip geworden, en zo zie je ook Android versies zonder Google diensten op toestellen in de markt.
En dan heb je nog de keurende instanties en goedkeurende afspraken met telecom partijen zoals KPN, Vodafone, T-Mobile, Orange, etc.

Google heeft in de opzet van Android al de nodige wijzigingen doorgevoerd en probeert die voor die fabrikanten die de Google diensten erop leveren ook te verplichten om toe te passen, maar daarna blijft het nog steeds de verantwoordelijkheid van de fabrikant om dat goed toe te passen.

En al die patches moet een fabrikant dan nog wel testen, tegen hun eigen aanpassingen in Android aan, voordat ze uitgerold kunnen worden, want eigen camera app die speciale dingen mogelijk maakt moet niet kapot gaan door een camera driver update want heel het internet is boos op je. Die driver niet updaten, en een enkele tech nerd is boos op je.
Plus die update testen kost tijd en geld, dat goedgekeurd krijgen kost ook tijd en geld. Maar het halve internet zoekt de best bang for buck telefoon om te roepen dat ze de snelste hardware hebben.
En de andere helft koopt een Android telefoon van Samsung of Google want die hebben hun updates wel goed voor elkaar. En dit laatste gedrag, in combinatie met wet en regelgeving, is wat fabrikanten echt in beweging zet, en je ziet een Oppo en Xiaomi nu op hun high end toestellen ook bepaalde update garanties geven, maar goedkoop zijn die modellen dan niet echt.

Overigens zou ik nog steeds graag het Windows model zien op de mobiele telefoons. Je koopt de hardware plus je koopt het OS, en dat je voor die 100 Euro extra gedurende de levensduur allerlei updates kunt verwachten via de OS leverancier. Dit model met losse roms stamt uit een tijd dat hardware gewoon zo beperkt was en het niet aan kon, dus moesten de roms zwaar geoptimaliseerd zijn, maar nu bewijzen custom rom projecten of Android GSI projecten dat dat niet meer zo nodig is.

[Frame164]

Dat fabrikanten dat doen is ook wel weer logisch. Die hebben gezien wat er op de PC markt is gebeurd: daar is geen enkele manier om je als fabrikant echt te onderscheiden zodra er Windows op wordt gezet. De gebruiker ziet exact hetzelfde ongeacht het merk PC. Met als gevolg: race to the bottom qua prijzen. Dat willen ze met smartphones niet.

[swhnld]

Dat willen ze misschien niet, maar doen ze wel. Uiteindelijk zal het neerkomen op een kosten baten afweging. Wat kost het onderscheid versus de investering. Kun je dat ook met een launcher bereiken en daaronder alles generiek?

En eerlijk, op de PC markt zijn er ondertussen gewoon gevestigde namen alsmede niche merken die winst maken en trouwe klanten hebben. Onderscheid is er op uiterlijk, kwaliteit en service.
En formatteer eens een recente Dell, Lenovo of HP, na schone installatie komen er spontaan meegenomen apps op voor driver updates. Dus ook op Windows kun je tegenwoordig personaliseren naar je merk.

[Ralph84]

Dit is ook weer één van de redenen dat ik ben overgestapt naar een Pixel phone.
Qua software is dit gewoon zoveel beter. Minder opslag nodig voor de OS, minder bloatware, eenvoudigere instellingen, veel snellere updates. Trouwens, een app installeren of updaten gaat ongelofelijk snel (geen idee of dit ook ligt aan de OS).

Ik heb een One Plus en een Samsung gehad, maar de volgende tel wordt weer een Pixel, 100%!

[Reactie gewijzigd door Ralph84 op 23 juli 2024 03:54]

[CAPSLOCK2000]

Kijk ook eens naar LineageOS, dat is pas echt vrij van bloatware. Als je dat eenmaal gewend bent dan voelt iedere andere telefoon als een broeinest van reclame en bloatware. Zo'n beetje alles van OnePlus wordt uitstekend ondersteunt en gaat jarenlang mee, dus als je nog een OP hebt liggen zou ik het zeker een keer proberen.

[WOteB2]

Er wordt wel eens wat geroepen over Motorola, maar mijn Moto G9 plus krijgt nog steeds iedere maand een update. Dat vind ik wel netjes.
Verder is een Motorola ook zo goed als kaal. Die paar Moto zaakjes kun je nog uitzetten ook.

[pporrio]

Precies de reden waarom ik een paar dagen geleden een Google Pixel 6a heb aangeschaft.

Na enkele updates is de huidige Android versie op mijn Pixel 6a geüpgraded naar versie 13. En security updates tot 2027 is wel zo fijn.

Hiervoor de nodige mindere ervaringen qua updates gehad met o.a. toestellen van Sony, Samsung en Motorola, waarbij de laatste echt slecht was in het uitleveren van (security) updates.

[gekko90]

Maar die vlieger gaat niet op als de fabrikant van een van de chips geen nieuwe patches maakt. Dat is juist HET probleem van android. Google kan patchen wat ze willen maar als firmware/drivers nog door chipbakkers gemaakt moeten worden en niet komen dan zit je

[g_v_rijn]

Google's hardware met eigen processor is nu dus in het voordeel.

[gekko90]

Alleeen als ze alles maar dan ook alles zelf in house maken. Als ze ook maar 1 chip welke firmware/drivers nodig hebben dan kom je alsnog terecht in het bovenstaande probleem.

Als je verder gaat kijken wat de Tensor cpu serie eigenlijk is dan zul je zien dat het een product is op basis van licenties van andere chipfabrikanten met onder andere MALI gpu’s

[Frame164]

Maar met Google loop je sowieso het risico dat ze van het ene op het andere moment met een product stoppen. En daar zouden ook bepaalde kritische componenten van Android bij kunnen zitten.

[Reactie gewijzigd door Frame164 op 23 juli 2024 03:54]

[ggj87]

Dit weten gebruikers natuurlijk al héél lang. Het probleem met Android is dat iedere fabrikant een eigen versie wilt hebben. Daardoor moet alles nog eens aangepast worden voordat de update uiteindelijk naar de telefoons kan worden gedownload. Het zou beter zijn als fabrikanten stock Android zouden gebruiken, dat is veel beter. Geen bloatware en snellere updates

[Frame164]

Voor de fabrikant is dat absoluut niet beter. Het maakt dan niet meer uit welk merk je koopt als ze allemaal dezelfde software draaien. Die gaan dat dus echt niet doen.

[kiddingguy]

Zoveel Android toestellen, zoveel verschillende fabrikanten-versies.
En wanneer een toestel (volgens fabrikant) EOL is, of minder interessant is om te patchen wordt het gewoonweg niet gedaan kennelijk. Slechte zaak, en de consument is de dupe hiervan.

Ik zou zeggen -zoals @Splorky ook zegt- één OS-variant, en laat de fabrikant maar een schilletje erom ontwikkelen.

In dat opzicht is Apple zo gek nog niet met hard- én software bij één bedrijf. En updates "garanderen" van/tot toestellen die 5-6 jaar oud zijn.

[Stefan22]

Het is ook gewoon een tekortkoming van Android. Windows draait op duizenden configuraties zonder tussenkomst van fabrikanten voor updates, maar bij Android kan het niet. Technisch zal het ongetwijfeld een lastig verhaal zijn, maar er mag wel eens wat aan gedaan worden door Google.

En dan bedoel ik niet een Project Treble, want aan dit artikel is maar weer goed te zien dat dat niet heeft geholpen.

[Reactie gewijzigd door Stefan22 op 23 juli 2024 03:54]

[Wolfos]

Dat is waarschijnlijk Google's insteek met Fuchsia:
https://en.wikipedia.org/wiki/Fuchsia_(operating_system)

Er is alleen veel tijd nodig om zoiets van de grond te krijgen, als je een volwassen OS wilt vervangen.

[Quitzcused]

Project Treble werkt gewoon, alleen kost het veel tijd om alles over te zetten. Elke nieuwe android versie heeft meer losstaande modules. Heel veel wordt nu al via de play store meegenomen op android 12 en 13

[Stefan22]

Project Treble bestaat al sinds Android 8. We zijn nu bij Android 13. Mooi dat er veel wordt meegenomen via de Play Store, maar het belangrijkste, de beveiligingsupdates, nog altijd niet.

[Quitzcused]

Beveilingsupdates worden al doorgestuurd, alleen niet alle onderdelen van het OS kan aangeraakt worden op het moment

[blorf]

Het "'uitrollen" dat alle OS-en voor mobiele hardware vereisen is noodzakelijk gemaakt in het belang van de leverancier van het verplicht meegeleverde OS. In tegenstelling tot wat ze beweren, zitten Android en iOS zo ver mogelijk van modulair af als ze kunnen, Deden ze dat niet, dan zou dat ervoor zorgen dat de eigenaar van het systeem permissies kan opeisen en de OS-maker technisch overbodig maken.

Deze Google-onderzoeker is dat absoluut aan het verbergen door te suggereren dat fabrikanten verantwoordelijk zijn voor veiligheidsproblemen die bestaan omdat de gebruiker, of software namens die gebruiker nergens bij kan want die heeft de permissies niet.

[brigada]

Ik ben zeer tevreden over GrapheneOS op mijn Pixel Pro 7 anders, wordt vaak geupdate

[Commendatore]

‘Water is nat.’

[Royytje]

https://www.rijksoverheid...0en%20beveiligingsupdates.

Geldt hier nou ook dat de verkopende partij hier voor verantwoordelijk is?

[brammetje1994]

De verantwoordelijkheid ligt altijd bij de verkoper, omdat jij als consument geen afspraak/contract hebt met de fabrikant.

Wij weten allemaal dat de verkoper geen controle heeft over het uitbrengen van dergelijke updates, maar als de fabrikant niet voldoet aan de plichten welke worden gesteld kan jij de verkoper daar op aanspreken. Dat zal uiteindelijk leiden tot een risico-afweging van verkopers en wellicht denken die dan na of zij wel een dergelijk product wilt verkopen.