Linux-bug maakt veel Android-toestellen kwetsbaar

De onlangs ontdekte fout in de Linux-implementatie van rfc 5961 treft ook een groot aantal Android-telefoons, dat zegt beveiligingsbedrijf Lookout. Alle Android-versies met de Linux-kernel vanaf versie 3.6 zijn kwetsbaar, dat komt neer op toestellen met Android 4.4 of hoger.

Lookout schrijft dat de kwetsbaarheid met kenmerk cve-2016-5696 in de Linux-kernel is opgelost op 11 juli, maar dat er nog geen patch beschikbaar is voor de Linux-kernel in Android. Naar schatting van het beveiligingsbedrijf maakt dit 1,4 miljard toestellen kwetsbaar. De bug is weliswaar moeilijk te gebruiken door kwaadwillenden, maar een aanval kan worden uitgevoerd zonder dat daar een man-in-the-middle-positie voor nodig is.

Een van de Lookout-onderzoekers vertelt aan Ars Technica dat de kwetsbaarheid een risico vormt voor Android-gebruikers die geen gebruikmaken van een beveiligde verbinding, bijvoorbeeld via https of een vpn. Zo zou een aanvaller kwaadaardige javascript-code kunnen injecteren in de actieve verbinding en een vals inlogscherm kunnen tonen om gegevens te achterhalen. Een dergelijke actie zou ongeveer een minuut in beslag nemen en geschikt zijn om te worden ingezet in een gerichte aanval. Het lek wordt voor het Android-team als 'gemiddeld' beschouwd, zo stelde een Google medewerker tegenover Ars Technica.

De kwetsbaarheid in kwestie werd door onderzoekers van de universiteit van Californië gepresenteerd op de Usenix-conferentie in Austin. De foutieve implementatie van rfc 5961 in de Linux-kernel maakt het mogelijk dat een aanvaller kan vaststellen of twee partijen met elkaar in verbinding staan door een tcp-verbinding. In het geval van een onbeveiligde verbinding kan een kwaadwillende verzonden pakketten manipuleren. Een beveiligde verbinding kan alleen verbroken worden.

Reacties (137)

De schrijver van dit artikel heeft helaas de klok wel horen luiden, maar heeft geen idee waar de klepel hangt.

Ten eerste, er bestaat géén "rfc 5961 protocol". RFC 5961 (met hoofdletters, hou toch eens op met het afschuwelijk lelijke schrijven van afkortingen in kleine letters) beschrijft een een aantal mogelijke aanvallen op TCP-verbindingen. Je zou hoogstens kunnen schrijven dat het een fout is in de implementatie van het TCP-protocol, maar zelfs dat is niet helemaal correct omdat het geen aanpassing van het TCP-protocol is, maar slechts de wijze waarop een host reageert op bepaalde TCP-segmenten.

RFC 5961 is bedoeld om TCP-verbindingen robuuster te maken. Één van de aanbevelingen - degene waar het hier met name om gaat - is het beperken van het aantal "Challenge ACKs", om op deze manier het lastiger te maken om het juiste TCP Sequence nummer te achterhalen.

De implementatie van Linux was, in tegenstelling tot wat het artikel zegt, juist. Het idee in de RFC was niet goed.

Het probleem, dat in de whitepaper waar in de laatste paragraaf naar gelinkt wordt, wordt beschreven is het ongewenst lekken van informatie door deze beperking. In de Linux implementatie werd het aantal Challenge ACKs beperkt tot 100 per seconde. Als je nu wilt weten of Host A en Host B met elkaar communiceren, stuur je een pakketje naar één van de twee hosts, dat een Challenge ACK zou moeten triggeren. Daarna stuur je 100 pakketjes vanaf je eigen host die óók een Challenge ACK triggeren. Krijg je 100 antwoorden: er is géén communicatie tussen Host A en B, krijg je 99 antwoorden, dan is er blijkbaar al een Challenge ACK verstuurd en is er dus sprake van een TCP-sessie tussen Host A en Host B.

De oplossing die in de Linux kernel is geïmplementeerd is het verhogen van de limiet van 100 naar 1000 en het toevoegen van een random factor, waardoor die limiet niet precies 1000 is, maar "ergens in de buurt van 1000".

Dat er

nog geen oplossing is gevonden voor de Linux-kernel in Android

is ook klinkklare onzin. De oplossing is het implementeren van de patch in de Android kernel. Dat is blijkbaar nog niet gebeurd.

De oplossing is het implementeren van de patch in de Android kernel. Dat is blijkbaar nog niet gebeurd.

Als toevoeging op deze perfecte post:
Android is een aangepaste linux kernel. Dus de meeste aanpassingen vanuit de kernel landen vanzelf in Android. Aangezien Android niet elke week van een nieuwe kernel wordt voorzien kan het heel even duren voordat een dergelijke aanpassing wordt doorgevoerd.

Maar dit betekent ook dat praktisch ELKE linux machine net zo kwetsbaar is. Het is daarom ook gewoon 'clickbait' om Android expliciet te noemen. Want hoe zit het met die miljoenen/miljarden routers, computers, servers, ...

Overigens vraag ik me sterk af waarom Google naar een reactie gevraagd wordt. Juist de linux kernel is HET onderdeel waar fabrikanten voornamelijk verantwoordelijk voor zijn en waar de meesten ontzettend LAKS mee omgaan. Als een toestel geen update krijgt naar een nieuwe Android versie is dat 9 van de 10 keer een antieke kernel die een of andere binary blob heeft voor het video gedeelte. Dus ga maar naar Samsung of Qualcomm voor antwoorden!
Microsoft / Windows heeft/had precies hetzelfde probleem. Iedereen heeft wel hardware gehad die bij een OS upgrade ineens niet meer werkte. Die scanner of webcam die geen driverupdate kreeg. Dat is EXACT hetzelfde probleem, het enige 'lastige' van een smartphone is dat alles in 1 pakket zit. Je kunt niet dat ene incompatible onderdeel verwijderen, omdat je smartphone meestal meteen gehandicapt is.
Heb je een recente kernel voor je smartphone die alle drivers (werkend) bevat kun je vrij eenvoudig de laatste Android op je telefoon zetten (Bv. met cyanogenmod)

Het ligt inderdaad vrijwel altijd in GESLOTEN drivers, iets wat eigenlijk niet eens legaal is (!)

En hoe will google dat oplossen? Een nieuwe kernel schrijven in MIT zodat gesloten drivers legaal worden en dus nog meer problemen kunnen veroorzaken. Zucht.

+3 Bedankt voor je aanvulling. Vindt wel dat je erg fel reageert op de schrijver die een net artikel heeft geplaatst. Interpretatie foutjes blijven menselijk, zelf op tweakers.

p.s. rfc staat in dit geval gewoon voor 'Request for Comments'. In het engels ga je niet ieder woord starten met een hoofdletter, wordt enkel gedaan voor de herkenbaarheid, de generator spuugde ze altijd in lowcase uit.
Taaltechnisch gezien is zowel rfc als RFC onjuist taalgebruik. Iemand erop wijzen dat je het moet schrijven als RFC lijkt me dus altijd ongepast.

sorry dat ik terug kom op een niet belangrijk onderdeel, maar het is toch echt DNS, TCP/IP FTP, etc en RFC.

Dat iets gebruikelijk is betekend niet dat het andere fout is of uberhaupt goed is.

Laten we het even een keer duidelijk stellen, zonder allerlei vergelijken die nergens op slaan:

Google KAN NOOIT iets doen aan het probleem van updates zonder door de EU, VS en China van de markt te worden verwijdert vanwege monopolistisch gedrag.

Een simpel voorbeeld. Amlogic is uitgekomen met de S905, de 'nieuwste' kernel die zij leveren aan fabrikanten is 3.14.29. We zijn ondertussen bij 4.7 aanbeland, dus dit is een prehistorische kernel... van een product dat je zo in de winkel kunt kopen.
Een stel hobbyisten zijn 'uit ellende' maar begonnen met een open source versie.

Wat betekent dit concreet:
Google heeft geen contract of relatie met Amlogic, hooguit hebben ze een contract/relatie met de fabrikant die de chips gebruikt. Google heeft dus ook GEEN toegang tot de source code of knowledge base van Amlogic. Maar zelfs Amlogic heeft een probleem omdat zij de Mali 450 GPU gebruiken die dus ook weer van een andere fabrikant is. Dus zij hebben ook maar beperkt toegang tot code (NDA's etc.). Dus als de Mali 450 GPU niet werkt met de nieuwe kernel kan Amlogic dus ook geen nieuwe kernel uitbrengen. Als Amlogic geen zin heeft in het uitbrengen van een nieuwe kernel, dan heeft de fabrikant een probleem en dan moet de fabrikant het dus OOK nog willen. En dit alles komt uiteindelijk op het bordje van Google die amper invloed heeft op 'dit spel'.

De enige oplossing is dat Google zelf SoC's gaat produceren met bijbehorende drivers en Android gaat limiteren tot die SoC's. Exact wat Apple dus ook al doet, zij maken de chips 'in eigen beheer' zodat ze deze ellende niet hebben. Want zelfs de 'Nexus' lijn heeft al serieuze problemen gehad met SoC's die niet meer ondersteund werden na een korte tijd.

Ik denk dat de EU, China & VS niet heel 'blij' zouden zijn als Google zijn 'verantwoordelijkheid' zou pakken en alleen nog maar 'hun' SoC's zou toestaan...

Exact wat Apple dus ook al doet, zij maken de chips 'in eigen beheer' zodat ze deze ellende niet hebben.

Apple is een beetje een speciaal geval. Zij doen dat namelijk niet om deze ellende te voorkomen maar om voor te lopen op de rest van de fabrikanten die gewoon een chipje van Qualcomm of Samsung in de telefoon proppen. (Weet je nog dat ze opeens met een 64-bit SoC in hun telefoon kwamen? De rest is daar toen halsoverkop ook mee begonnen maar liepen alsnog een jaar achter.) Apple heeft namelijk, itt de meeste andere fabrikanten, wél de resources om zelf SoCs te laten bakken en kan dus SoCs ontwerpen en maken precies met die features die zij willen, waar de rest 't moet hebben van wat Qualcomm en Samsung bedenken.

Maar tegelijkertijd, als ze dat niet zouden doen, zou dit geen probleem zijn want Apple is groot genoeg in afname om een fabrikant tot in lengte der dagen de SoC die ze gebruiken te laten ondersteunen.

Ik denk dat de EU, China & VS niet heel 'blij' zouden zijn als Google zijn 'verantwoordelijkheid' zou pakken en alleen nog maar 'hun' SoC's zou toestaan...

Ik denk 't wel. Stel je voor de grap eens voor wat er zou gebeuren als Microsoft zou afdwingen dat alle fabrikanten alleen nog maar Intel CPU's zouden gebruiken. Wat je voorstelt is nog een stap erger: Microsoft die zelf CPU's gaat bakken en vervolgens afdwingt dat als je Windows wilt draaien, dat je die CPU's moet gebruiken.

Dat Google, net als Apple, in hun eigen telefoons hun eigen SoC stopt is prima maar niet dat ze anderen dwingen dat ook te doen.

[Reactie gewijzigd door CyBeR op 16 augustus 2016 19:41]

Ik denk dat het een leuk effect zou kunnen geven, maar weet niet of het in het belang is van alle partijen. Met nieuwe Linux versies komen af en toe performance verbeteringen, accu verbeteringen en dergelijke. Als ze nu forceren dat de Nexus lijn netjes word onderhouden, lopen dus alle Nexus gebruikers lekker met lang ondersteunde hardware met de langste batterijduur en de beste performance.
Gezien de concurrentie veelal bestaat uit grote internationals die het waarschijnlijk gewoon te weinig interesseert om echt druk te zetten op hun leveranciers, worden die dan ook aangespoord en hebben ze de keuze tussen failliet gaan of fatsoenlijke driverondersteuning regelen.

Ja, dat krijg je met de afwezigheid van degelijk updatebeheer. Voor Linux distros is zo'n bug niet zo'n probleem. Die rollen gewoon een nieuwe kernel uit en het is opgelost. Eventueel moet de distro de patch nog backporten naar hun eigen kernel. Maar op Android ben je afhankelijk van de fabrikant van de telefoon, en die verkoopt je liever een nieuw apparaat dan dat ie zo'n bug fixt. De enige mogelijkheid om dit tegen te gaan is centraal updatebeheer, maar daarmee raken fabrikanten ook een deel van de mogelijkheden tot aanpassen kwijt. Maarja, wat heb je liever: een veilige telefoon of een waar de fabrikant onnodige rommel bij heeft gestopt?

Dus de oplossing: scheiding van hardware en software, net als bij Linux. De belangrijkste voorwaarde is dan dat fabrikanten hieraan meewerken: open-source drivers voor alles, zodat de community het kan onderhouden.

Helaas, geld gaat eerst. Binary blobs gekoppeld aan bepaalde versies van omliggende software zijn het perfecte voorbeeld van planned obsolescence.

opensource drivers gaat noooooit gebeuren, maar zelfs zonder dat kan het prima werken als OEM afspreken elke gebruikte chip minimaal 3 to 5 jaar van driver updates te voorzien tegen dan de laatste kernel.. zelfs met blobs is het dan al beter dan dat het tot nu toe ooit geweest is..

Vooral frustrerend omdat Google besloten lijkt te hebben het probleem van de gesloten drivers op te lossen door een nieuwe MIT licensed kernel te schrijven - zodat ze uberhaupt niet meer open hoeven te zijn. Gaat echt een security slachting worden.

Kan op internet weinig vinden over een nieuwe kernel van Google. Heb je hier een bron voor?

Er is nog erg weinig info over maar er zou een MTI licensed kernel bij zitten: https://en.wikipedia.org/wiki/Google_Fuchsia

Je verwacht te veel van open source. Hoeveel open source gebruikers hebben daadwerkelijk wel eens een code review gedaan? Er zit geen structuur in, je moet het maar net treffen dat iemand het leuk vind om het te doen.

Hoeveel open source gebruikers hebben daadwerkelijk wel eens een code review gedaan?
Dat is een beetje heel erg niet waar; (meer dan ) de helft van de linux kernel / drivers -source (en vooral de drivers) wordt door bedrijven gedaan, die linux als platform nodig hebben; ze zijn niet alleen makers, maar ook gebruikers.
daarbij testen ze niet alleen hun eigen produktie, maar ook die van anderen waar ze afhankelijk van zijn.

die bedrijven besteden 10.000-en uren aan code maken, testen en fixen, in additie van de 10.000-en uren die individuen er in steken.

de klinkklare recht voor zijn raap kritiek waar onder andere linus torvalds inmiddels beroemd voor is, spreekt jouw bewering ook tegen.

er is code review, en wel door diegenen die er verstand van hebben en een (levens) belang bij hebben dat dat goed gebeurt.

[Reactie gewijzigd door mraix op 16 augustus 2016 14:20]

Dit zeg je inderdaad goed. Maar 90℅ of meer geeft niet om security want de telefoon moet mooi roze zijn etc daarnaast bereikt dit nieuws hun niet eens dus ze weten het waarschijnlijk ook niet... en het interesseert ze niks wat niet roze.

[Reactie gewijzigd door HKLM_ op 16 augustus 2016 08:50]

Maar waarom doet Apple het dan wel goed? Apple is razend populair + hun security is redelijk goed in orde, terwijl waarschijnlijk de gemiddelde Apple gebruiker "don't care about security" is. Android is goed op weg om het nieuwe Win9x te worden.

In die zin doet Google het ook goed met hun Nexus lijn.

Op PC's doet Microsoft ook updates voor Dell's, HP's en zelfs Acer. Google moet gewoon z'n verantwoordelijkheid nemen en voor alle android de OS updates uitrollen.

Google moet gewoon z'n verantwoordelijkheid nemen en voor alle android de OS updates uitrollen.

Google maakt vrijwel geen telefoons en anders dan mensen denken ook zelfs geen compleet telefoon OS. Android is in feite een pakket bibliotheken en source code waar andere bedrijven een telefoon OS mee maken. Google levert met de Play Store er dan weer de grootste app collectie op aarde bij. Soms passen fabrikanten weinig aan, soms herschrijven ze grote delen van de code.

Maar Google kan dus geen updates leveren, want een groot deel van de telefoons kijkt niet eens naar de Google update servers. Plus Google heeft vaak geen flauw benul wat de telefoonfabrikanten gewijzigd hebben.

Het Android update probleem is inherent aan de manier waarom Android verdeeld is qua rolverdeling. De uiteindelijke leverancier van de OS software, zoals de eindgebruiker krijgt bij Android, heeft enkel belang bij de verkoop van nieuwe telefoons, en noemt zichzelf dus doorgaans ook geen software leverancier maar telefoonmaker.

1) Google is niet de eigenaar noch verantwoordelijk voor Android, dat is AOSP.

2) Google rolt heel geregeld veiligheidsupdates uit naar al haar toestellen en maakt de code hiervan beschikbaar zodat andere fabrikanten deze ook gemakkelijk kunnen implementeren.

Wat moeten ze dan in hemelsnaam nog meer doen? Waarom zou Google in hemelsnaam verantwoordelijk zijn voor OS-updates van haar concurrenten

Je zou kunnen stellen dat Google deze situatie had moeten voorzien en harder z'n best had moeten doen om dit te voorkomen. Ik denk dat ze dat achteraf zelf ook wel gewild hadden, getuige de Nexus-lijn en de steeds hardere roep om toch te patchen.

Misschien hadden ze een stok achter de deur moeten houden om de fabrikanten te dwingen om te upgraden*. Of hadden ze de Android zo moeten inrichten dat de fabrikanten niet nodig zijn om te patchen. Of ze hadden de licentie zo vrij moeten maken dat je echt je eigen firmwares kan maken zonder stevige nadelen en risico's.

Het is zo iets als dat je ziet dat de bovenbuurman die op vakantie is de kraan open heeft laten staan. Dat is niet jouw fout, maar als je de kraan niet dichtdraait ben je mede verantwoordelijk voor de schade. Je was in de positie om een hoop ellende te voorkomen en hebt het niet gedaan. Dat is nalatig.

Verschuilen achter AOSP vind ik hier niet terecht. Het gaat hier om keuzes die Google in het verleden gemaakt heeft aangaande de opzet van Android. De AOSP is daar net zo zeer deel van als het wel of niet hebben van een centrale updateprocedure. Daarmee is Google nog niet verantwoordelijk voor alles wat AOSP doet maar hier mag je Google echt wel op aanspreken.

Ondertussen hebben ze wel een manier gevonden om hun eigen apps te updaten en features toe te voegen via de Playstore. Security bugs in het OS kunnen echter niet op deze manier worden gepatched. Omdat mensen wel de nieuwste apps uit de playstore krijgen ervaren ze niet dat ze op verouderde en onveilige software draaien. Wederom op zich niks wat Google direct verkeerde heeft gedaan, maar je kan je afvragen of dat wel de beste keuze was voor hun gebruikers en of ze het probleem zo niet groter hebben laten worden.
Net zoals ze het meeleveren van de standaard apps verplicht stellen hadden ze het leveren van upgrades verplicht kunnen stellen.

* Ik ben erg voor software-vrijheid en tegen gedwongen upgrades. Bovenstaande is dus niet noodzakelijk mijn mening, maar ik snap wel dat Google hoe dan ook een grote rol speelt in de situatie waar we ons in bevinden.

[Reactie gewijzigd door CAPSLOCK2000 op 16 augustus 2016 11:23]

Inderdaad. Google is het probleem niet.
Maar de fabrikanten moeten het mogelijk maken dat je gewoon een update doet naar een nieuwere versie, net als dat je een Windows computer met OEM Windows er op kunt updaten.

Inderdaad. Google is het probleem niet.
Maar de fabrikanten moeten het mogelijk maken dat je gewoon een update doet naar een nieuwere versie, net als dat je een Windows computer met OEM Windows er op kunt updaten.

Google is het probleem niet, maar Google heeft het probleem wel gecreëerd.

Android komt uit de hand van (een door) Google (overgenomen bedrijf). Dat ze het Open Source hebben gemaakt zodat iedereen er aan mee kan werken is leuk, maar verandert er niets aan dat in de basis Android al verrot is wat betreft updatebeleid. Dat is weldegelijk door Google gecreëerd dan wel in stand gehouden.
En daar plukken wij nu de vruchten van

Het voornaamste probleem voor fabrikanten lijkt me de integratie met hun eigen schilletje, naast de 'macht' die providers op dit punt nog hebben.
Als ze de drivers en schillen open source zouden maken, en de radio stack scheiden van de rest van het OS, denk ik dat ook Android vanuit AOSP OTA geüpdatet zou kunnen worden, en kan de community helpen om de schillen en drivers te onderhouden.

Ik snap even niet hoe je tot de conclusie kan komen dat Android in de basis al rot is... dat is namelijk evident niet zo.

dat is namelijk evident niet zo.

Het meest gebruikte besturingssysteem ter wereld kan niet worden geüpdatet vanuit een centrale codebase (AOSP), maar moet voor iedere update langs minstens 3 partijen: Google, de fabrikant van de smartphone en de providers. Waarbij zowel Google als de smartphonefabrikanten er vaak aparte codebases op nahouden.
Core API's kunnen niet zonder tussenkomst van fabrikanten of providers worden gepatched.
Dat noem ik een rotte basis.

Nee dat is een domme implementatie van de fabrikanten, imho. Met de core is niets mis, die kan prima geüpdatet worden. Het probleem zit hem erin dat fabrikanten er bewust voor kiezen dat niet te doen, dat is een heel ander verhaal. Dan is het huidige eco-systeem waar fabrikanten dat kunnen doen rot, maar Android zelf niet. Kijk naar Nexus, kijk naar custom ROM's zoals Cyanogen. Draait allemaal op tig apparaten en kan prima gepatched worden in de core...

Google is strikt genomen het probleem niet. Wel krijgen ze er negatieve publiciteit door, blijkbaar gezien de reacties hier. En als ze kunnen verplichten dat de Google apps worden meegeleverd zouden ze ook aanvullende eisen kunnen stellen aan de veiligheid. Bijvoorbeeld dat een mobiel OS minimaal 24 maanden ondersteuning krijgt voor beveiligingsupdates. (binnen 2 maand gerealiseerd)

Google is heel expliciet met verkopers dwingen om play services mee te leveren. Dus de verkoop kan afgedwongen worden, dat zelfde kunnen ze dan eenvoudig doen met veiligheidsupdates.

V.b.

- Leverancier van apparaat gebruikmakend van de diensten verplicht zich updates in de categorieën "veiligheid" en "privacy" binnen een periode X door te voeren.

Dat zelfde kunnen ze via, via ook afdwingen bij de provider via hun play store apps.

V.b.

- Aanbieder van app verplicht zich veiligheids updates tijdig aan te bieden.
- Indien een aanbieder een op Android gebaseerd platform aanbiedl verplicht de aanbieder daarmee te voldoen aan de voorwaarden die gesteld worden aan hardware leveranciers.

Natuurlijk pseudo voorwaarden maar op zo'n manier moet iets haalbaars zijn. Als het wel gedaan wordt om de play store te pushen, waarom security updates dan niet? Kwestie van prioriteiten?

Google is dan niet verantwoordelijk voor Android, maar ze zijn wel volledig verantwoordelijk voor OHA Android, dus dat is hier geen argument.

En je zegt het zelf al: zodat "fabrikanten deze ook gemakkelijk kunnen implementeren". Juist daar wringt het schoentje, het moet niet makkelijk te implementeren zijn, het moet makkelijk te distribueren zijn.

Dit is pertinent gewoon niet waar. Android is een open-source besturingssysteem ontwikkeld door AOSP. Het gros van de ontwikkelingen komt inderdaad van Google ontwikkelaars, maar dat vrijwaard andere fabrikanten (die net zo goed pullrequests kunnen doen naar AOSP) niet van hun verantwoordelijkheid.

De fabrkant bepaald welke kernel versie er in hun rom komt, aangezien ze ook specifieke zaken moeten aanpassen op de hardware.

Jouw analogie is inderdaad perfect hoe het zou moeten werken.

Zou een mooie boel wezen. Als de Jumbo rotte vis in de schappen heeft, en gaat wachten tot Albert Heijn de betreffende visboer op de vingers tikt omdat ze gewend zijn dat AH dat eigenlijk altijd wel doet. En dan, als de AH het probleem opgelost heeft, alsnog willens en wetens de verkeerde vis blijven bestellen en op een of andere manier toch AH de schuld geven

Een fabrikant is gewoon zelf verantwoordelijk voor zijn producten. Als hier exploits in zitten heb je die te fixen. Ongeacht wat andere fabrikanten doen. Google gaat al heel ver door zoveel open-source ontwikkeling te doen. Daar mag iedere andere fabrikant zijn voordeel mee doen. Maar verwachten dat Google de software van al haar concurrenten gaat patchen is natuurlijk je reinste onzin.

[Reactie gewijzigd door mcDavid op 16 augustus 2016 13:12]

Je verbuigt de zaken wel heel erg. Jumbo gaat echt niet zelf vissen omdat ze een keer rotzooi geleverd krijgen. Ze verkopen dan nee, precies wat de overige android klanten doen!

De kernel is niet de software van de concurrent.

[Reactie gewijzigd door rko4u op 16 augustus 2016 15:02]

Google doet het dus wel goed op zich, de andere fabrikanten volgen echter niet. Ze hebben net als Apple het voordeel dat ze maar een handjevol apparaten hoeven te ondersteunen. Niet dat Google niet ook e.e.a. moet verbeteren, maar regelmatig updaten met Android kán dus wel gewoon. Maar er spelen heel veel factoren mee, en de vergelijking met Windows is ook niet helemaal eerlijk.

Google kan op één of andere manier wel afdwingen dat bepaalde apps van Google geinstalleerd moeten worden, maar een degelijk updatebeleid afdwingen is er niet bij. Google is hierin niet helemaal onschuldig lijkt me.

Dat komt omdat Google wel hun eigen software compatibel kunnen houden met de basis functies van Android, maar Google de fabrikanten niet kan verplichten hun custom kernels, custom launchers en custom apps voor lange tijd te updaten omdat dat heel veel geld kost.

Maar dat komt omdat ze het product van Microsoft gebruiken, het is niet open source dus valt niet aan te passen(Tenminste het mag niet).
Android is open source dus fabrikanten mogen er mee doen wat ze willen, ze mogen halve OS slopen.

Hierdoor heeft google er ook geen controle op, maar is het systeem wel erg populair fabrikanten kunnen er alles mee.
Google kan dus ook geen updates hierdoor uitrollen, omdat elk android OS op elke telefoon anders is.

Google kan het wel maar wil het niet.

Ze kunnen Google Apps ook verplichten.

Wat ze zouden kunnen (maar nooit doen) is alle Google Apps onwerkbaar maken bij een te lage Android versie. Maar ja dat kost reclamegeld en daar gaat het Google in de eerste plaats om.

Dat kan toch nooit werken op oudere toestellen? Stel dat jij nog een telefoon met Jelly Bean hebt en er komt geen update meer voor uit omdat dat de telefoon te traag zou maken, mag je dan geen YouTube en play store gebruiken?

Of een controle op bepaalde updates, dus niet op upgrades. Maar nogmaals, dat gaat Google toch nooit doen want minder reclamegeld. Ze kunnen het echter wel.

Al bestaat er wel iets als een kernel, die elke fabrikant gelijk kan houden waardoor het updaten ineens een stuk makkelijker wordt.

Daarnaast is een bugfix voor PC's van verschillende fabrikanten ook een meteen beschikbaar voor phone, xbox, tablet, HoloLens vanwege Windows OneCore.

Omdat op de laptops van andere fabrikanten Windows + troep bij zit, troep kan weg doormiddel van deinstallatie of door gewoon een schone Windows te installeren.

Bij Android ligt dat anders, fabrikanten passen de boel aan en verzorgen de updates, in het geval van Windows verzorgt Microsoft deze.

Als jij cyanogenmod op je telefoon installeert verzorgt deze de updates, daarom komen er voor vele toestellen vaak zelfs dagelijkse updates uit.

Zolang niet Google maar Android fabrikanten de updates verzorgen blijft het een zooitje, en juist daar moet Google z'n verantwoordelijkheid voor nemen en zelf de updates verzorgen op smartphones, net als dat Microsoft dat met Windows doet.

In 99% van de gevallen is Google niet verantwoordelijk want de leveranciers geven een versie uit. Google geeft heel vaak nieuwe versies of patches uit echter implementeren de leveranciers dat niet !

Maar nog steeds niet zo goed als een willekeurige PC waar je Linux op draait. Als Apple of Google (Nexus) een (beveiligings)update niet uitbrengt voor jouw toestel, dan krijg je die dus gewoon niet.
Bij Linux is iedere update er voor iedere computer, ongeacht hoe nieuw of oud die is. Voor (hele) oude kistjes zijn er zelfs minder uitgebreide versies die ook gewoon geüpdatet worden met de nieuwste beveiligingspatches. Dat bedoelt @The Zap Man hierboven met het volledig loslaten van hardware en software.

Zoals met de Nexus 5 die tot 11-3-2015 verkocht werd maar waar Android N al niet meer op wordt gesupport?

Omdat iPhone==Apple en omdat Android!=google

Apple heeft alles zelf in de hand, google niet want de meeste telefoons zijn niet van google maar van samsung, sony, htc, etc..... Niet te beheren dus.

Wel te beheren, maar niet door Google alleen.

Overigens hoef je je niet blind te staren over het softwarebeheer van Apple. Hoewel Apple alles in eigen hand heeft, slaagt het er toch in om regelmatig flinke missers te maken bij de updates.

heb nog nooit een iphone gehad of iets van apple maar ik zeg altijd tegen mijn hoogbejaarde vader. Neem apple. kan je niets aan slopen haha

Goed advies is duur, zeggen ze wel eens.

maar hun populariteit is niet aan hun security te danken. waar aan wel, daar kun je lang over praten. ze waren de eerste met een smartphone van de nieuwe generatie en het is een goed apparaat in vele opzichten. Verder denk ik (imho!) dat dit van toepassing is op Apple producten: Velben Good. (interessante read in elk geval!)

Apple doet het goed omdat de userbase veel updates krijgt en wil installeren. Met een adoptierate van ver boven de 80% in de eerste week is dit een enorm succesvolle formule. Apple heeft derhavle ook het goede update beleid: we update de software onafhankelijk van het type apparaat. En alle gebruikers wereldwijd krijgen hem zodra het kan. Geen gefaseerde uitrol of drie maanden vertraging doordat een provider er nog overheen moet.

Dat leidt toch nog niet altijd tot goede resultaten. Regelmatig brengt Apple een nieuwe versie van iOS uit die al na enkele weken gepatcht moet worden.

Nog even afgezien van het trager worden van oude apparaten, terwijl mijn 4 jaar oude Galaxy S3 als een nieuwe draait op de nieuwste Android-versie.

Ios en Android hebben beide zo hun voor- en nadelen.

terwijl mijn 4 jaar oude Galaxy S3 als een nieuwe draait op de nieuwste Android-versie.

Custom Rom zeker? De S3 Neo gaat namelijk al niet verder dan 4.4.2 (maar heeft wel stagefright patch gehad). Ik zie niet hoe je dit de laatste versie kan noemen daar we nu op android 6 zitten en 7 er ook al weer bijna aankomt.

Een 4 jaar oude iPhone 5 draait daarentegen wel op de laatste versie van iOS en pakt straks ook lekker de update mee naar 10.

Dat Apple na een aantal weken al een patch uitbrengt is alleen maar mooi. Dat betekent juist dat ze het systeem serieus willen beveiligen. De meeste lekken vind je namelijk pas in de eerste weken na release als een kwart miljard mensen extra naar je ontwikkelde product kijekn en gaan testen. Sinds de open beta's is dat al
Minder, maar nog steeds worden de belangrijkste dingen pas gevonden of bekend gemaakt na release.

Inderdaad, een ROM van CM. Ik noem dat de laatste versie van Android, omdat het versie 6 is en versie 7 nog niet uit is.

De ROM is voorzien van de laatste veiligheidspatches.

Daarmee is ontzenuwd dat een Android toestel na 2 jaar niet meer veilig zou zijn. En sterker nog, omdat Android steeds beter en lichter wordt, draait de Galaxy S3 beter dan toen deze nieuw was.

Bij Apple ligt het allemaal heel anders. Voordeel is dat de gebruiker zelf niet hoeft na te denken en automatisch wordt voorzien van de nieuwste updates.
Vergeet echter de nadelen niet:
- ios wordt steeds zwaarder, waardoor oude toestellen het niet goed meer doen op nieuwe ios versies.
- waar je bij Android nog kunt kiezen om op een oude Android versie te blijven en deze te blijven updaten, word je bij iPhone gedwongen om de nieuwste major ios-versie te installeren.
- er zijn geen andere smaken ios dan die Apple voorschrijft.
- Apple maakt soms fouten bij updates omdat er onvoldoende getest is.

Dat er veel gebruikers nodig zijn om een product te testen is echt een zwak excuus. Neem een niet werkende wifi bij sommige iphone modellen. Dat moet niet kunnen. Alsof je een auto met falende remmen koopt.

Verder wil ik opmerken dat bij Tweakers encyclopedieën volgeschreven worden over veiligheidslekken bij Android, maar dat dit in de praktijk niet tot enige maatschappelijke ontwrichting heeft geleid en dat Android onverminderd populair is in Nederland (itt Apple).

Tsja en dat tel ik dus niet mee, want dat is voor de gemiddelde consument dus niet eht een optie.

Neem een niet werkende wifi bij sommige iphone modellen. Dat moet niet kunnen. Alsof je een auto met falende remmen koopt.

ja ik ken het probleem. Dit is hardware gerelateerd en komt alleen voor bij de 4S en dan met name bij mensen die het toestel meermaals in de zon hebben laten opladen (gewoon binnen op een tafel bij een raam). Als er dan vervolgens een fikse update wordt geïnstalleerd raakt het toestel oververhit, maar kan het niet afsluiten vanwege de update.

Het is gewoon te repareren door een reball of reflow.

Maar laten we het vooral niet hebben over de falende flashchips in de S3 die menig toestel heeft gebricked.

Edit:

Dat er veel gebruikers nodig zijn om een product te testen is echt een zwak excuus.

dat is geen zwak excuus dat is hoe veiligheidslekken en zero days worden gevonden. Hoe goed je team ook is je gaat nooit alles vinden.

[Reactie gewijzigd door supersnathan94 op 17 augustus 2016 10:34]

Dit was geen veiligheidslek.

Hoe bedoel je "dit was geen veiligheidslek"?

De vorige "zero-day patch" was voor sommige iPad Pro's die spontaan brickten door een software dingetje. Dit is bij Samsung echter ook vaak zat gebeurt. Slecht excuus dus.

Je gaf aan dat veiligheidslekken zo lastig te vinden zijn.
Het wifi-probleem bij de iPhone was echter geen veiligheidslek. Dat was gewoon slecht getest. Slordig voor een fabrikant die alles in eigen beheer doet.

Nee dat kan je niet testen. Dat is een veel te specifieke use case waarbij het toestel buiten specificaties (veel te warm, in direct zonlicht) is gebruikt.

Het komt alleen bij de iPhone voor, maar het ligt natuurlijk nóóit aan Apple.

Oh nee hoor. Ik heb ook samsungs en huaweis ter reparatie gehad met wifi problemen.

Overigens worden samsungs geplaagde door defecte simkaart lezers, maar dat ligt uiteraard ook niet aan Samsung.

Dit specifieke probleem is toch echt een Apple probleem.

maar dat ligt uiteraard ook niet aan Samsung.

Ik gebruik 'm niet vaak, maar hier komt-ie dan:

Lees m'n reactie nog eens. Teksten uit context halen ben je kennelijk erg goed in.

Kijk supernathan94, als ik aangeef dat het wifi probleem van Apple een wifi probleem van Apple is, en jij komt met een voorbeeld van Samsung waarin je sarcastisch opmerkt dat het "uiteraard ook niet aan Samsung" ligt, dan denk ik dat we klaar zijn.

Nee ik denk het niet.

Het wifi probleem met de iPhones is niet slecht getest. Wat moet Apple dan doen? De update niet installeren bij mensen waarvan het toestel aangeeft dat een gebruiker het toestel niet binnen de specificaties gebruikt? Er staat duidelijk in de handleiding dat je hem niet in open zonlicht moet neerleggen. Ik heb het een keer gehad met mijn iphone 5 die gewoon afsloot om het toestel te beschermen. Had em tijdens een ritje op het dashboard liggen. Apparaat was te heet om vast te pakken. Sindsdien heb ik er altijd een luchtstroom van de airco op gericht staan.

Dergelijke dingen zijn gewoon randgevallen waar je niet tegenaan kan testen aangezien je dan gaat testen dat je je specificaties inderdaad goed hebt opgesteld. Daar is niets nuttigs aan want dat wist je al.

Dit probleem doet zich (zoals ik al zei) net zo goed voor bij toestelen van Samsung. Daar heb ik het namelijk ook al een aantal keer gezien op de reparatieafdeling. Alleen veel minder omdat dit wat meer @random gebeurt en niet massaal doordat mensen na release bij Apple wereldwijd tegelijk de update krijgen en niet gefaseerd over meerdere maanden.

Dit is gewoon een hardware defect doordat het toestel veel te warm is geworden. Tijdens het updaten van de firmware is er alleen niets wat er voor kan zorgen dat het toestel uitschakeld om beschadiging te voorkomen. Alleen interne throttling van de SOC.

Dat is hetzelfde als "spontaan" defect gaande simkaart lezers bij personen die net niet voorzichtig genoeg de simkaart eruit halen (het schuif systeem is niet heel best voor de kwaliteit daarvan na meerdere malen wisselen).

Het buiten de specs om defecten krijgen ligt uiteraard niet aan een fabrikant. Daarom heeft de fabrikant ook die specs opgesteld. De temperatuur specificaties zijn best ruim. Gemiddeld tussen de -5 en 50 graden omgevingstemperatuur tijdens bedrijf. Dat is in nderland zat. Ga je daarbuiten (met direct zonlicht ga je makkelijk richting de 60-70). Ga je daar natuurlijk dik overheen. Tijdens het updaten kunnen interne componenten dan dus vrij eenvoudig 100 graden aantikken. En dat is gewoon te veel.

OK, duidelijk.

Maar waarom doet Apple het dan wel goed?
Volstrekt onvergelijkbaar. Apple beheert zowel hard- als software, en heeft dus niks te maken met andere leveranciers die hun software wel of niet goed implementeren en/of updates wel of niet tijdig distribueren.

Ze houden het hele proces in eigen hand en kunnen daarom makkelijker en sneller updates doorvoeren: dan doen ze dat toch goed?

Voor 99,999% van de gebruikers zou dat wel de beste manier van werken zijn. Open systemen zijn leuk maar voor de meeste gebruikers moet iets gewoon werken. Niets meer en niets minder. Bij een wasmachine heeft toch ook niemand het erover dat je er een andere motor in moet kunnen zetten of de wasprogramma's moet kunnen aanpassen?

Om de wasmachinevergelijking maar door te trekken: de volgende Samsung wasmachine draait Android 6.0, stuurt jou een app als je was klaar is, mailt je moeder als er teveel gaten in je sokken zitten en je kan je eigen achtergrondje op de display zetten. In 2019 blijkt er een bug in Android 6.0 te zitten, maar je wasmachine wordt door Samsung niet meer geupdate want ze hebben 150 verschillende types wasmachines die allemaal een eigen aangepaste versie draaien. Een eco-hacker besluit dat jij je was niet heter dan 30 graden mag wassen en onderschept de mails aan je moeder en stopt ze vol met reclame van de hema waar de sokken in de aanbieding zijn ...

Het verschil is in essentie niet zo groot: je maakt een os en je kiest of je het onder controle wilt houden of niet.
Apple maakt de keuze tot volledige controle en beperkte keuze hardware; Google heeft gekozen voor vrijwel onbeperkte keuze in hardware en vrij weinig controle.

Noem het een vooruitziende blik maar het gefermenteerd appelsap smaakt beter dan de gefermenteerde koemelk.

Bij Apple gaat het toch nog regelmatig mis bij de updates.

Het verschil is in essentie werelds: of je alleen software schrijft of ook de hardware levert waar die software op moet draaien is een gigantisch verschil!
Niet voor niks draaien de Macbooks en dergelijke over het algemeen probleemlozer dan de gemiddelde Windowsbak: de hele infrastructuur is van begin tot eind in handen van de fabrikant.
Heeft overigens niks te maken met vooruitziende blik, maar alles met vendor-lockin!

denk je nu echt dat apple het goed doet om de security. ???

apple doet het goed, want updates (features),
want niche merk (hip populair - net als ooit eens blackberry)
om de interface (waar elke mongool zelfs mee uit de voeten kan: ten koste wellicht van de vrijheid voor mensen die meer willen).

maar veiligheid heeft daar niets mee van doen

Apple een niche merk? 1 miljard iPhones....

Apple is altijd laat, en zal nooit toegeven dat ze iets fout hebben gedaan.

denk maar even aan "Antenna-gate"

Je moest je telefoon echt als een mon*** vasthouden om de antennes te verstoren. Wmb netjes opgelost met de bumpertjes. Helaas zijn deze superslecht voor je housing en waren de toestellen er zo uit te pikken.

Apple heeft gewoon een monocultuur. Er zit geen variatie in het OS tussen de verschillende portables, het is allemaal iOS, hooguit in verschillende versies en met verschillende features die aan/uit staan. Daardoor is het updaten eenvoudig.

Windows Mobile doet dat ook, je hebt alleen verschillende versienummers en features die wel of niet werken op jouw telefoon, maar that's it. Eén platform voor alle hardware.

Android doet dat niet. Dat kan door elke telefoonboer helemaal customised geïnstalleerd worden. Nieuwe UI erop, bepaalde functies erin, eruit, noem maar op. Daardoor kun je wel centraal updates gaan zitten pushen, maar je hebt dan geen enkele garantie dat de wijzigingen die de fabrikant aan je OS heeft aangebracht, er niet voor zorgen dat je update de telefoon bricked.
Google had gewoon Android in eigen beheer moeten houden. De grootste klacht over Windows en iOS is dat het een relatief gesloten systeem is, maar juist dat zorgt ervoor dat de updates veel makkelijker verlopen.

Ach, als ik dit lees dan is het bij Apple ook niet allemaal 100% geweldig op beveiligingsgebied:
http://m.slashdot.org/story/314993

De grootste klacht over Windows en iOS is dat het een relatief gesloten systeem is, maar juist dat zorgt ervoor dat de updates veel makkelijker verlopen.

Voor verreweg de meeste gebruikers is dat geen klacht. Ook ik heb bewust voor een iOS (zakelijk) en een WP10 (prive) toestel gekozen, juist omdat het gesloten systemen zijn. Geen gezeik met support. In verreweg de meeste gevallen geldt: It just works. Bij Android is dat vaak precies andersom.

[Reactie gewijzigd door Trommelrem op 16 augustus 2016 09:16]

Heeft niks met gesloten te maken.
Ubuntu is ook open maar heeft gewoon een goed update beleid. Updates kun je gewoon installeren.
Waarom bij Android niet ?

Omdat ubuntu gewoon Ubuntu blijft op elk systeem het zelfde, dit is bij android niet het geval.
Bij android mag elke fabrikant het halve os slopen wat ze ook doen, hierdoor heeft google er geen controle meer op.

Het heeft wel degelijk met een gesloten systeem te maken. Voorheen distribueerden wij software onder een open source licentie aan klanten.
Daarmee had de klant de mogelijkheid om zelf wijzigingen door te voeren in de software en van die mogelijkheid werd ook gretig gebruik gemaakt.

Bij het uitrollen van updates werden wij echter keer op keer geconfronteerd met de problemen. Vragen over updates, problemen met updates, problemen met maatwerk en updates die niet werden uitgerold. In sommige gevallen werd er gewoon 3-4 jaar lang niet geupdate en als iets dan uiteindelijk stopt met functioneren ( *duh* ) dan krijg je een woedende eindklant aan de lijn.

We zijn gestopt met de distributie van open source software en overgestapt naar een gesloten systeem. Er zijn nog steeds vragen over updates, maar het zijn er minder. Er zijn vrijwel geen problemen met updates meer, maatwerk is uitgesloten en iedereen zit altijd op de allerlaatste versie.

Mijn Android toestel krijgt gewoon updates.
Ook mijn vorige Android telefoon, een 4 jaar oude Galaxy S3, is voorzien van de laatste veiligheidsupdates.
Ik denk dat jij onvoldoende op de hoogte bent van Android.

Maar veel andere toestellen van dezelfde leverancier krijgen weer geen updates. Dat maakt het nog wat complexer. Als je weet dat leverancier X netjes en tijdig updates uitrolt en leverancier Y niet, dan kan je daar je keuze op baseren. Nu moet je maar hopen dat er een update voor het toestel dat je gekocht hebt komt.

Ik draai er CM op. Ik wacht niet op Samsung.

Heb je al eens een test gedaan op het Stagefright-lek? Ik vrees dat dit niet opgelost is op je 'bijgewerkte'-s3.

(Stap eventueel over op CyanogenMod.)

Jawel, die is bijgewerkt.

Wanneer heb je dan voor het laatst een Android-update gehad?
Ongeveer vier maand geleden was mijn S3 ook geheel bijgewerkt, maar niettemin (nog) wel kwetsbaar voor Stagefright (getest met de app van Zimperium).
Ik draai nu op Cyanogenmod-Kitkat, dus ik kan het niet meer controleren voor Samsung-Android.

(Mijn S3 is wel een stuk sneller nu :-)

Sorry, ik zie nu dat je het over stock Android had. Ik draai CM13 op de Galaxy S3. Die heeft nu Android-beveiligingspatch tot 5 augustus j.l. bijgewerkt. Uiteraard geen Stagefright-lek meer aanwezig.

CM is idd zo veel beter dan stock Samsung...

Ook bij Ubuntu kan je lang niet altijd pakketten installeren of updaten, want ook daar kan custom software of bijvoorbeeld te nieuwe/legacy software voor conflicten zorgen... Dat is bij Android net zo, gezien de fabrikanten er zelf een laag overheen gooien.

Ik gebruik zelf ook W10M op een Lumia 535, maar omdat ik voorheen nog met een ouwe Nokia C1 rondliep is dat geen probleem - ik had geen hele riedel apps die ik per sé moest kunnen blijven gebruiken, en veel meer als een beetje Whatsapp doe ik er toch niet mee. Ik heb alleen wel even gechecked of deze ook kon upgraden naar W10M, en dat is zo.

Wat me dan wel opvalt is dat W10M op zo'n budgettoestelletje gewoon vele malen soepeler aanvoelt dan (niet zo budget, maar wel oudere) Android-toestellen. Plus dat hij met enige regelmaat toch 's nachts opnieuw ligt op te starten, omdat er weer updates binnen zijn gelopen, wat er duidelijk op wijst dat de ondersteuning prima in orde is.

Maar wat moet die 90% eraan doen dan?
Ze kunnen dit toch niet zelf oplossen? Dat moet toch dmv een update gedaan worden ipv even een setting te veranderen.

Ook al heb je gelijk wat dat roze betreft, ik ga niet akkoord dat 90% niet om security geeft. Kijk naar hoe mensen auto's kopen: ik ken er maar weinig die NCAP als een keuzeparameter meenemen, laat staan dat ze een merk links zouden laten liggen omdat die een slechte reputatie hebben wat betreft airbags.

En toch ben ik er zeker van dat iedereen wil dat de veiligheid gewoon in orde is als het erop aankomt (en vertrouwen we een stukje op de regulering, denk ik?).

Volgens mij geldt hetzelfde voor zoiets als smartphones. De dag dat je phone gebricked wordt door een hack, of dat iemand is gaan shoppen met je creditcard, vind je die dingen wel belangrijk.

En persoonlijk vind ik dat fabrikanten daar mee hun verantwoordelijkheid mogen nemen (en erop gewezen worden, misschien wel met wetgeving die bijvoorbeeld een minimumtermijn van security patches moet voorzien).

On-topic: gelukkig heeft mijn HTC nooit een update naar 4.4 gekregen, dit lek mis ik dus

Wel grappig je verhaal en dan zelf een telefoon gebruiken die zwaar achter loopt kwa updates.
Of je moet een custom rom draaien.

Leuk verhaal van de NCAP, maar (ik en velen met mij) heb gewoonweg geen geld voor een 5 sterren NCAP wagen.

Volledig irrelevant & offtopic, mijn HTC ligt hier tussen het kinderspeelgoed, maak je geen zorgen

Er zullen inderdaad mensen zijn die zich dat niet kunnen permitteren maar daar ging het mij ook niet om. Het punt was dat zij die dat wel kunnen, daar niet mee bezig zijn bij hun selectie, maar wél willen dat het in orde is.

En in alle eerlijkheid, ik denk dat de meeste mensen die een Dacia Duster kopen, zich ook wel een Ford Fiesta of een Renault Clio kunnen permitteren. Van beide scoorde de vorige generatie trouwens ook al 5 sterren.

Duidelijk antwoord, met duidelijke uitleg. Je hebt gelijk, heb te vroeg gesproken en te weinig uitgezocht

Ik let wel degelijk op de NCAP score. Dat is stukken belangrijker dan de vermeende veiligheid van ios of onveiligheid van Android.

Bij een auto hebben we het immers over fysieke veiligheid, terwijl de veiligheid van de smartphone hoofdzakelijk een theoretische exercitie op Tweakers is.

Het lek wordt voor het Android-team als 'gemiddeld' beschouwd, zo stelde een Google medewerker tegenover Ars Technica

Ach, zolang Google het lek als 'gemiddeld' beschouwd zal het wel niet zo'n vaart lopen toch?
Ik bedoel wat zijn nou 1.4 miljard gebruikers?

En daarbij het is niet de schuld van Google, het is de schuld van de fabrikanten. Oh nee, het is de schuld van de providers. Oh nee wacht, het is de schuld van de gebruiker, die moet gewoon alles over een vpn doen, wat stom.

Het lek is "gemiddeld" omdat, zolang de server niet kwetsbaar is, de kans dat je de correcte parameters gokt nagenoeg '0' is.

Waar het gevaarlijk wordt, is als je via de server informatie kan krijgen over een verbinding (server zelf, of via een advertentie netwerk, oid) . Je hebt dan de informatie om het lek ook effectief te misbruiken.

Risico afweging wordt gemaakt aan de hand van de impact van de bug en hoe effectief die te misbruiken is. Voor servers is deze bug zeer vervelend, omdat je daar 80% van de parameters "gratis" krijgt. Voor clients (en met name mobiele diensten) kun je DoS aanvallen tegen google en facebook nog relatief effectief doen, maar echt "Gevaarlijk" misbruik is een stuk moeilijker

Dit heeft helemaal niets te maken met updatebeheer. Dit is gewoon een lek. Zoals er in ieder systeem lekken zijn. Kan me toevallig nog een artikel herinneren dat op iOS ook ingebroken kon worden dmv een nep inlogscreen via e-mails. Als voorbeeld.
Ieder systeem heeft lekken, en er zijn gelukkig zat getalenteerde white hat hackers die voor een vergoeding deze lekken opsporen en melden. Omdat android met extreme overmacht het meest gebruikte mobiele besturingssysteem is, en omdat google flink betaald voor het melden van lekken, komen er vaak beveiligingsproblemen aan het licht. En dat is goed. Liever dit als dat er zero day leaks aan 3e partijen verkocht worden. En die partijen hebben voor ieder besturingssysteem wel een paar zero day leaks op de schappen liggen voor de hoogste bieder. Dat zagen we wel met het fbi/iphone verhaal.

Edit:

Ongewenst. Wat is er ongewenst aan mijn comment. Te veel mensen weten echt niet hoe ze moeten modereren op tweakers. Als je het niet met me eens bent, dan kan je een discussie met me aan gaan, graag, ben benieuwd naar je uitleg, maar een ongewenst geven op een volledig on topic comment. Sneu.

[Reactie gewijzigd door Ruw ER op 16 augustus 2016 10:15]

Zo'n lek moet gedicht worden. Zonder een degelijk updatebeheer worden deze lekken alleen op de nieuwste high end toestellen en de toestellen die stock Android draaien gedicht. Samsung heeft er bijvoorbeeld totaal geen zin in om hun Galaxy Pocket Neo goedkope bagger telefoon te updaten. Als er een centraal updatebeheer voor Android vanuit Google was geweest, was dit geen probleem geweest. Nu zitten miljoenen mensen met een goedkope of oudere smartphone met een lek dat nooit gedicht zal worden.

Ik heb geen woord over iPhones of iOS gezegd, dus waar je dat vandaan haalt is mij een vraag.

De prijs van de toestellen hoort niet in verhouding te staan met wel/geen updates. Als ze bij Android een centraal updatebeheer opgezet hadden en fabrikanten niet een (om het maar even grof te zeggen) verkrachte Android versie op hun telefoons zouden zetten, had elke telefoon updates kunnen krijgen en het had geen enkele extra moeite gekost voor de fabrikant. Win-win lijkt mij.

Maar doordat fabrikanten zelf hun updates moeten regelen hebben ze er geen zin in om dit voor alle toestellen te doen en doen ze het alleen maar voor de nieuwste en duurste.

Geen zin? Ze zouden wel gemotiveerd kunnen worden om er zin in te hebben. Wat zouden ze doen als onze wetgever een security leak beschouwt als een defect aan het toestel, dat je mag terugbrengen binnen garantie.

De eerste rechter die dit precedent schept, legt vast dat alle toestellen security updates moeten krijgen tot 2 jaar na de laatste verkoop (of je krijgt een evenwaardig alternatief als het niet meer te fixen is).

De lobbywereld zal wel moord en brand schreeuwen, maar volgens mij zou zo'n regeling in no time het ganse probleem oplossen.

Jammer dat een uitspraak van rechters alleen gelden tot aan de grens.
Gevolg is dat na een dergelijke uitspraak er alleen nog maar Iphones en de vlaggenschepen verkocht worden, naast een bult grijze import vanuit landen waar die uitspraak niet geldt...

hoewel ik groot voorstander van zo'n uitspraak zou zijn, zeker als het op Europees nivo afgedwongen kan worden

zo goed dat ze regelmatig een release weer blokkeren om dat die gebrickte iPhones produceert.....

en met security zijn ze niet heel erg vlot of mededeelzaam.......

Behalve dan dat Linux (Mint) adviseert je kernel niet te updaten ten zij je het absoluut nodig hebt en weet wat je doet. Wat voor de groeiende groep gewone gebruikers (de Android equivalenten) dus opgevolgd wordt.

Dat moet Mint weten. Wat 1 distro doet is niet ineens maatgevend voor de hele Linux community. Ik heb zelf Ubuntu- en Fedora-machines en daar komen de kernel updates gewoon met de andere updates mee.

Bij Mint ook: ik heb ook nog een kernel-update staan. Alleen moet je die wel apart installeren.

Eigenlijk jammer dat, wat dit betreft, Android niet meer afkeek van GNU/Linux en een soort van package beheer integreert in het OS ecosysteem voor het toegankelijker maken voor eindgebruikers o.i.d.

Want van fabrikanten hoef je inderdaad niet veel te verwachten helaas.

Daar hebben ze helaas niet bij het begin van Android aan gedacht en daarvoor moeten ze nu op de blaren zitten..

Ik lees net dat we met zijn allen op een grote afvalberg met oude telefoons zitten. Heel goed mogelijk dat wij, door het gebrekkige updatebeleid geneigd zijn om na het uitblijven van (security) updates maar weer een nieuwe telefoon te kopen terwijl dat helemaal nog niet nodig is. Ik heb nog een ruim drie jaar oude Sony die nog heel goed werkt maar die geen updates meer krijgt. Nu ben ik toevallig een handige jongen die het wel voor elkaar krijgt om er een Cyanogen versie op te zetten, maar hoe zit dat met de grote groep mensen die deze handigheid niet hebben? Juist. Die kopen allemaal een nieuwe telefoon waardoor de afvalberg steeds hoger wordt.

Er zijn ook genoeg autos die langer op de weg zouden kunnen blijven rijden als je handig bent met sleutelen. En toch worden er elk jaar weer meer autos verkocht. Genoeg mensen kopen een nieuwe telefoon om emotionele redenen, niet omdat hij technisch is afgeschreven.

Zeker waar. Alleen is een groep die denk dat de telefoon stuk is of niet meer werkt. Terwijl soms al een simpele reset of update zou helpen. M'n zus wist bijv. niet eens goed dat ze uberhaupt haar telefoon kon updaten naar nieuwere versie van het os.

Wat heeft het voor doel om een VPN te gebruiken tegen deze bug? Normaal zou je pakketten injecteren in de verbinding tussen telefoon en webserver, met een VPN zou je dan toch simpelweg de pakketten injecteren in de verbinding tussen VPN server en webserver? Of gaat dat ineens niet dan?

jeroenr's uitleg volgend, neem ik aan dat je moet weten om welke telefoon het gaat en welke website bezocht word (A en .
Dat kun je met een apparaat op een onveilige WIFI hotspot misschien nog raden/traceren, (IPscan, Hotel login server) maar op een willekeurig apparaat dat via VPN op het internet komt is dat mogelijk lastiger te raden?

Ik draai RR op m'n Nexus 5x met de ElementalX kernel (1.19). In de instellingen>about phone>kernel version staat er 3.10.73. Zouden dit soort telefoons ook kwetsbaar zijn? Het lijkt me dat het met root acces kwetsbaarder is(?)

Ja, want 3.10 is hoger dan 3.6 lijkt me...

Oh, sorry verkeerd gelezen.

Kan zijn dat er al een nieuwe kernel beschikbaar is. Franco heeft vandaag ook een nieuwe kernel gereleased voor o.a. de N5X.

"Alle Android-versies met de Linux-kernel vanaf versie 3.6 zijn kwetsbaar, dat komt neer op toestellen met Android 4.4 of hoger."

Kernel versie en android versie staan los van elkaar.
Zo draait de mijn oude xperia mini (en alle andere van de serie) op kernel 3.4 voor zowel 4.4, 5.0 en 6.0.

Dank voor de uitleg.

Ik denk dat Android zelf per definitie geen onveilig OS is, maar het onveilig wordt door de lakse houding van fabrikanten om updates en patches met regelmaat en acceptabele termijn door te voeren. Tenslotte verdienen fabrikanten niks aan al die updates; zij willen veel liever dat je ieder jaar een nieuwe smartphone koopt.