Google: lek in Linux-kernel betreft geen 66 procent van Android-toestellen

De onlangs ontdekte kwetsbaarheid in de Linux-kernel is volgens Google aanwezig in een 'significant kleiner' aantal toestellen. De ontdekkers schatten de hoeveelheid kwetsbare Android-apparaten in eerste instantie op 66 procent. Een patch zou vanaf 1 maart beschikbaar zijn.

Android-beveiligingshoofd Adrian Ludwig meldt in een blogpost dat Google de patch voor de kwetsbaarheid inmiddels beschikbaar heeft gemaakt. Deze moet aanwezig zijn op alle toestellen die vanaf 1 maart een beveiligingsupdate uitvoeren. Hij voegt toe dat Google niet van mening is dat 66 procent van alle Android-toestellen kwetsbaar is, maar dat het om een 'significant kleiner' aantal gaat.

Dit baseert hij op het feit dat Nexus-toestellen niet kwetsbaar zouden zijn voor gebruik van de kwetsbaarheid door applicaties van derden. Daarnaast zouden apparaten met Android 5.0 of hoger beschermd zijn door SELinux. Daar komt bij dat volgens Ludwig veel toestellen met Android 4.4 niet de kwetsbare code bevatten, omdat nieuwere Linux-kernels niet vaak voorkomen op oudere apparaten. De kwetsbaarheid komt voor in Linux-kernel 3.8 of hoger.

Ludwig stelt ook teleurgesteld te zijn dat de ontdekkers van de bug, Perception Point, niet eerst het Android-team hebben benaderd voordat zij het lek publiceerden. De kwetsbaarheid geeft een lokale aanvaller de mogelijkheid om via de Linux-keyring-functie code uit te voeren in de kernel en daarmee root-toegang te verkrijgen.

Reacties (96)

Vind het toch wel een vreemde reactie.

'Geen 66% van de Android toestellen.' maar er wordt geen aantal gegeven. Als er iemand is die weet hoeveel toestellen er nog in gebruik zijn met deze of gene versie van Android, dan is het toch wel Google.

Idem met de kennisgeving. Uiteindelijk is het nieuws openbaar gemaakt op hetzelfde moment als de patches voor de Linux kernel beschikbaar waren. Tussen de lijnen zegt google dus dat de Linux kernel unpatcht moet blijven totdat Google een fix klaar heeft. Die dan wellicht nooit wordt uitgerold op de meeste toestellen. Dat is er toch ver over? De kern van het probleem is hier niet de communicatie van Perception Point, maar het brakke veiligheids- en updatemodel van Android.

maar het brakke veiligheids- en updatemodel van Android de meeste fabrikanten.

Android (op nexus apparaten) krijgt netjes iedere maand security-updates. Dat is on-par met Windows en zelfs (veel) vaker dan iOS. De fout die google wel aangerekend kan worden is dat ze in het verleden fabrikanten toegestaan hebben om het op deze manier te verkopen... maar aan de andere kant is dat ook weer juist (een deel van) het succes van android.

Als je kijkt naar de details van dit lek dan is het ook weer een storm in een glas water. De normale huis/tuin/keuken gebruiker zal hier nooit last van hebben, tenzij ze zelf bewust beveiliging uitzetten en de daarbij gegeven waarschuwingen negeren.

Nee, eigenlijk toch wel echt Android. Dat dit soort dingen niet in de 'core' zit (de Play Services?) - wat niet aangepast kan worden door een ander, dus enkel door Google via bijv. de Play Store - ligt toch echt aan Android zelf. Het beste zou zijn om beveiliging patches dus via de Play Store te laten gaan, zodat gebruikers niet afhankelijk zijn van de fabrikant van het toestel.

Het zit in de Kernel, die door alle fabrikanten aangepast wordt voor de hardware en waar ze de source onder de GPL beschikbaar hebben.

Google treft geen enkele blaam, je moet bij de telefoon fabrikanten wezen.

Dan krijg je dus wel gevallen zoals deze. Iets wat toch niet zo handig is met een OS als Android, waar ontiegelijk veel verschillende telefoons voor zijn. Ik bedoel, naast de grote fabrikanten heb je ook nog duizenden kleinere. Mag je verwachten dat iedereen dit (of ander lekken) gaat updaten?

Maar als het in de kernel zit, wordt het wel wat lastiger ja.. Kunnen ze daar ook nog wat aan doen? Heeft Play Services niet "admin-rechten"? Of krijgen we dan bricked toestellen.

[Reactie gewijzigd door Luca op 21 januari 2016 13:26]

Of krijgen we dan bricked toestellen.

Dat is inderdaad de enige uitkomst als Google dat zou doen ja

Of de drivers moeten minder in de Linux kernel geïntegreerd worden. De Windows kernel kan namelijk ook gewoon worden geüpdate zonder dat ineens allerlei drivers omvallen.

Dat kan ook gewoon. Je kan drivers als module aan de kernel toevoegen. Of je kan ze er inhaken. Met embedded systems zoals telefoons moet de systeemdata zo klein mogelijk zijn. Ze compileren dan alles zonder de drivers die ze niet nodig hebben. (als het goed is)

Volgens de consumenten bond mag je dus binnen een redelijk termijn na aanschaf updates verwachten. Ze hebben Samsung daarom aangeklaagd. Want in de praktijk doet niemand dit.

Als je een redelijke termijn updates wil voor je telefoon dan heb je beperkt keuze bij android: De Nexus telefoons en in iets mindere mate bij een net uitgebracht flagship toestel van een grote fabrikant. Of een telefoon die goed door CyanogenMod ondersteund is voor de handigere tweaker :-)

Wil je lang updates krijgen dan zit je aan een Microsoft of Apple telefoon te denken. Vrijwel alle WP8 toestellen krijgen Windows 10 bijvoorbeeld. tegenover die langere update periode staat dan wel mogelijk minder frequente updates dan bij een Nexus toestel.

Yep, vrijwel niemand doet dit en de concurrenten hebben het iets beter voor elkaar. Voor de consument is dit natuurlijk knap lullig, een beperkte keuze als je een up-to-date OS wil hebben qua software en niet zelf bezig wil gaan met custom ROMS e.d. Dan kom je inderdaad al snel uit bij iets als een Nexus. Nu is het met de high-end lijnen vaak wel iets beter, maar zelfs dan is het altijd nog maar onzeker.

Dan kun je zeggen, Google moet harder optreden tegen de fabrikanten die Android gebruiken zodat ze die updates wel gaan pushen, maar gaat zoiets werken en kan dat ook echt?

Bij Linux distributies gaat het gewoon prima. Je update al je software vanuit repositories en daardoor heb je altijd vrij snel een bijgewerkte kernel. Bij Linux worden alle drivers ook gewoon met de kernel meegeleverd, daarom werkt veel hardware gewoon gelijk out of the box. Omdat de toestel makers voor elk toestel een andere Linux kernel meeleveren (met verschillende drivers), in plaats van een enkele gestandaardiseerde kernel, zorgen ze ervoor dat ze zichzelf en vooral de gebruikers in de vinger snijden.

Op een desktop maakt het ook niet veel uit of je nu een paar honderd extra drivers meelevert. Op een schijf van een terabyte maakt een GB meer of minder niet uit.
Als je echter op je telefoon ineens een stapel extra drivers mee moet gaan leveren, dan heb je aan dat budget-geheugen van 8 GB niet meer genoeg - iets waar nu al veel over geklaagd wordt. Allicht dat ze daar de onnodige bloat uitslopen, want dan kun je nog gewoon een smartphone met 8 GB verkopen (dat je dan effectief maar 1,5 GB kunt gebruiken maakt niet uit) in plaats van noodgedwongen 16 GB te moeten gaan inbouwen.

In dit geval klopt het dat je bij de fabrikanten moet aankloppen. Maar als je bijvoorbeeld stagefright bekijkt dan heb je het ineens over een library die Google wel degelijk zelf had kunnen patchen en pushen naar toestellen. Er is geen enkele reden waarom fabrikanten aan die bibliotheek aanpassingen moeten maken.

Android had voor de kern van het OS (al dan niet zonder de kernel, hoewel die in theorie ook kan wanneer fabrikanten drivers modulair inladen) een updatemechanisme moeten hebben zoals zovele andere besturingssystemen. Centraal beheerd door 1 partij. Is een bepaald onderdaal aanwezig op de telefoon? Dan moet die centrale update repository in staat zijn om dat onderdeel bij te werken.

Exact. Dit is wat ik bedoelde! Een kernel is natuurlijk wel weer iets anders, maar ook met het stagefright probleem kwam dit in me op. Ik snap nog steeds niet waarom Googe dit überhaupt niet doet, het scheelt zoveel gezanik en problemen.

[Reactie gewijzigd door Luca op 21 januari 2016 15:36]

Updaten via Google Play Services helpt de gebruikers zonder Google software anders ook niet.

Maar dat lijkt me voor Google dan ook geen probleem Dat stuurt alleen maar meer mensen naar Android met Play Service...

Het succes is idd dat ze fabrikanten vrij gelaten hebben, nu plukken ze daar de rotte vruchten van door falend update beleid van die fabrikanten.
Wie is de schuld, de fasbrikant of google.
Beide natuurlijk, de fabrikant moet updaten doet het niet. Google verplicht ze ook niet, heeft dat nooit gedaan maar wel gratis android en google verdiend toch aan android. via de play store en zoekmachine.
Google is dus net zo schuldig.

Het is natuurlijk vaag dat ze geen cijfers noemen en wat is significant ? De helft 33% is significant minder maar 33% zis nog steeds veel te noemen.

Nu zeuren ze dat ze eerst naar google moesten komen. Tja google publiceert ook wel eens dit soort zaken en geeft anderen dan x dagen, zo niet hup de exploit gaat de markt op.
Daarnaast zelf al zouden ze naar google gekomen zijn, de oudere androids worden toch moeilijk of niet geupdate.

Ik wou net zeggen 'Het gaat toch om een kwetsbaarheid in de Linux kernel? Waarom dan eerst de Android devs waarschuwen, i.p.v. de Linux community?'

Ik wou net zeggen 'Het gaat toch om een kwetsbaarheid in de Linux kernel? Waarom dan eerst de Android devs waarschuwen, i.p.v. de Linux community?'

Google vindt zichzelf gewoon erg belangrijk is natuurlijk wel iets voor te zeggen, Android is waarschijnlijk de meest gebruikte Linux variant (bij consumenten in ieder geval) maar aan de andere kant, ze kunnen zelf ook gewoon de kernel releases in de gaten houden.

Ze hebben natuurlijk hun eigen linux kernel gemaakt, gebaseerd op een LTS standaard linux kernel
https://en.wikipedia.org/...ting_system)#Linux_kernel
Ze zouden de bug dus kunnen patchen in hun eigen branch.

Google vindt zichzelf gewoon erg belangrijk

Elk bedrijf toch?

[Reactie gewijzigd door watercoolertje op 21 januari 2016 13:42]

Bij Google krijg je flink geld voor het melden van lekken. Bij de Linux community krijg je geen cent.

Uhm Red Hat enz. zijn ook linux community en die betalen ook gewoon voor fouten. Verschil is: je krijgt het vaak onverwachts.

Linux heeft de wereld veroverd, niet de desktop, maar wel de telefoon.

Dat heeft tot gevolg dat Andoid de meest verspreide 'linux distributie' is en een groot risico als er een beveiligingsfout word ontdekt.

Het is dan ook verstandig om Google in te lichten voor dat je zoiets openbaar maakt, zodat men vooraf maatregelen kan nemen.

Als ze het zelf uit de linux kernel moeten vissen, dan zijn ze altijd te laat.

M.a.w. Google vooraf inlichten is gewoon verantwoord handelen, Google niet inlichten is onverantwoord.

M.a.w. Google vooraf inlichten is gewoon verantwoord handelen, Google niet inlichten is onverantwoord.

Als Google ervoor zorgt dat de telefoonfabrikanten ervoor zorgen dat de gebruiker zelf de laatste kernel kan installeren, is het probleem opgelost. De oorzaak ligt in geplande veroudering.

Op mijn 10-jaar oude "reservecomputer" installeer ik zonder probleem een recente kernel, dat zou bij telefoons ook perfect kunnen als de telefoonfabrikanten meewerken.

Persoonlijk denk ik dat het geen slecht idee zou zijn als Europa ervoor zou kunnen zorgen dat alle smartphones die in Europa op de markt worden gebracht, verplicht gedurende 5 jaar, nadat de verkoop ervan stopt, van veiligheidsupdates moeten worden voorzien binnen een redelijke termijn, oftewel gedurende 2 jaar als men na ten laatste 1,5 jaar alle broncode vrijgeeft onder een geschikte opensourcelicentie en na 2 jaar dat ook doet met de broncode van de veiligheidsupdates in dat laatste halve jaar.

De fabrikant kan dan kiezen: geef ik mijn "geheimen" prijs na 1,5 jaar en riskeer ik dat ik in dat laatste half jaar nog heel veel lekken ga moeten dichten omdat mijn software slecht in elkaar zit? Of doe ik dat niet en ga ik tot 5 jaar na de laatste verkoop veiligheidsupdates maken voor stokoude smartphones?

Google kan er niet voor zorgen dat de gebruiker zelf de kernel kan installeren. Telefoons zitten vol met hardware waarvoor de drivers niet 'open' zijn, niet de minste hardware daaronder is de GPU.

Iedere telefoon heeft een andere combinatie en die weet de fabrikant. Het zal dus echt de fabrikant moeten zijn die de kernels uiteindelijk beschikbaar stelt.

Google neemt echter wel degelijk patches op in AOSP sources en verspreid deze onder android gebruikers. Het is dus er gewenst dat Google een update onder de fabrikanten kan verspreiden voordat deze algemeen bekend is geworden.

Daarna moeten wij als gebruikers helaas gaan klagen bij de fabrikanten omdat ze er niets mee doen.

Overigens de belangrijkste reden voor mij om Android vaarwel te zeggen, de waardeloze support van fabrikanten. Dat doen Apple en Microsoft beide beter.

Een verplichting voor fabrikanten om telefoons minimaal 2 jaar te blijven ondersteunen met updates en 5 jaar met security patches zou zeer welkom zijn. Maar moet die termijn dan ingaan. vanaf introductie of vanaf laatste levering?

Maar moet die termijn dan ingaan. vanaf introductie of vanaf laatste levering?

Laatste dag van levering zou ik zeggen want anders zet dit aan tot gesjoemel. Men zou bv. "dezelfde" smartphone geheime upgrades kunnen geven bij nieuwe productierondes zodat hij nog goed verkocht kan worden, maar "diezelfde" smartphone zou men dan veel korter moeten ondersteunen omdat het volgens de papieren geen nieuwe is. Dat toestel zou dan in de laatste jaren populair kunnen worden omdat dat "oude" model nog zeer goed mee kan en goedkoper is dan echte nieuwe toestellen. Helaas voor de kopers van dat snelle "oude" toestel stopt de ondersteuning dan zou moeten

Natuurlijk kan google daar wel voor zorgen. Ze stellen een heleboel erg strikte eisen aan fabrikanten om toegang te geven tot de Appstore - een goed veiligheids beleid of het netjes volgen van de GPL licentie (!!! doen veel fabrikanten niet) zou best aan dat lijstje eisen tegevoegd kunnen worden. Maar ze willen het niet/geven er niet om.

Je mag toch zelf kiezen wie je inlicht, het is wel handig als je Google inlicht maar het is geen verplichting, als je linux werkgroepen inlicht dan vind ik dat voldoende, Google hoort zich te bevinden in deze werkgroepen ze profiteren er namelijk goed van.

Google moet stoppen met dit soort kinderachtige uitspraken.

Als google een update mechanisme zou inbouwen voor het core systeem was er niets aan de hand.Voor de providers zou dit ook geen nadelig effect hoeven te hebben behalve dan dat de consumenten iets langer geneigt zijn met hun toestel te doen.

Ik wou net zeggen 'Het gaat toch om een kwetsbaarheid in de Linux kernel? Waarom dan eerst de Android devs waarschuwen, i.p.v. de Linux community?'

omdat android natuurlijk wel verantwoordelijk is voor het grootste deel linux devices in de wereld. In die optiek kan ik me het ietwat voorstellen. Desalniettemin dient zoiets gemeld te worden aan de hoofd ontwikkelaar, en dat is linux zelf.

het aandeel zal zeer laag zijn aangezien het aandeel dat kernel 3.8 of later geinstaleerd heeft minimaal is.
Veel roms worden uitgebracht met een oude kernel. dus als het 15% van de telefoons is lijkt mij dit al hoog.


Kernel 3.8 is uitgebracht in feb 2013 maar mijn lg g2 die gereleased is in aug 2013 draait nog steeds kernel 3.4 en dat terwijl hij later van 4.2 geupgrade is naar 4.4.2

Kortom hij loopt qua kernel nogal wat achter.
Dus ondanks dat de kernel als bijna 3 jaar oud is is het aantal telefoons daarmee waarschijnlijk zeer gering.
Ik heb helaas geen telefoon die nieuwer is maar misschien leuk om een polletje te doen met welke telefoon mensen hebben en welke kernel die gebruiken.

Na even googlen weet ik dat de S5 net als lg op kernel 3.4 zit en de s4 zal dus niet anders zijn (en alle andere samsung toestelen van deze jaren).Over de S6 kan ik niets vinden.
Xperia Z , Z2 , Z3 , HTC M8 hebben ook 3.4 als kernel.
Alleen van de laatste generatie is moeilijk te vinden welke kernel ze gebruiken maar zou mij niets verbazen als ze ook nog op een oude kernel draaien.

Ik denk dat het gedeelte dat 3.8 gebruikt zeer laag is

Mijn Note 4 910C: 3.10.9...We have a winner

Maar draait die intussen niet op Android 5.0 of hoger? Want daarbij zou volgens Ludwig het lek gedicht zijn.

ja was mij ook opgevallen dat om 1 of andere rede de note's zelfs verder achter liep dan de galaxy's die op hetzelfde moment uitgebracht zijn.

Ik denk dat het gedeelte dat 3.8 gebruikt zeer laag is

Ik denk dat ook. Mijn up-to-date oneplusone is ook 3.4.(67).
Ik herriner mij nog dat Linus of een andere kernel maintainer zich stoorde aan hoe ver de embedded wereld achterliep, kernel 2.2 werd nog gebruikt in nieuwe toestellen toen 2.6 al volwassen was.

Samsung galaxy note 4: 3.10.40-5932638
dat is dan wel weer op android 5.1.1
lijkt me dat een volledig up to date S5 ook rond die kernel zit, note en S serie telefoons van het zelfde jaar worden meestal een beetje gelijk gehouden.

Als je doel is om te zorgen dat het lek zo snel mogelijk dicht is in zo veel mogelijk Linux installaties.

Dan vind ik het slim als je alle partijen die een kernel aan een groot publiek of belangrijk publiek (kritieke infrastructuur bijvoorbeeld) leveren, direct na het vinden informeerd.

Wellicht stellen ze dan ook ditect experts beschikbaar die samen met jou de patches maken en testen.

Wellicht zelfs software schrijven die dit gat gebruikt om via internet root te krijgen te patchen en root te verwijderen. Ik noem maar een dwarsstraat. (Zulke virussen zijn eerder rond gegaan..)

[Reactie gewijzigd door djwice op 21 januari 2016 22:38]

Het zijn er maar 65%

Ludwig stelt ook teleurgesteld te zijn dat de ontdekkers van de bug, Perception Point, niet eerst het Android-team hebben benaderd voordat zij het lek publiceerden. De kwetsbaarheid geeft een lokale aanvaller de mogelijkheid om via de Linux-keyring-functie code uit te voeren in de kernel en daarmee root-toegang te verkrijgen.

Ja, no offense, maar contact opnemen met Google is niet bepaald makkelijk en zoals hierboven al vermeld wordt, het kan maanden duren voor je een reactie krijgt.

Graag zie ik ook een wat meer gebaseerde redenering voor "Significant minder dan 66%". Dat is mooi en aardig maar maakt dat de kat wijs dat het minder is dan 66% we kennen allemaal Google's laksheid voor Android updates, het zal eerder een hoger getal zijn.

Google is helemaal niet laks met Android updates, sterker nog Nexus toestellen draaien vrijwel altijd de laatste versies en worden jarenlang ondersteunt. Het zijn de fabrikanten die hun eigen schil over Android heen leggen en zelf het updatebeleid gaan bepalen, dus Samsung, HTC etc.

Als alles gewoon stock Android zou draaien en de fabrikanten lieten het updaten aan Google over net als bij MS en Apple dan was er niks aan de hand.

Google is er wel laks mee, veelste laat zijn ze gaan inzien van "Dit moet anders" terwijl Google gewoon even bij Microsoft, Debian of zelfs Apple naar binnen had kunnen gluren van "He, hoe bouw je een OS?". Want op die systemen kan ik de GUI en allerlei systeem functies ombouwen naar wat ik zelf wil, en het OS update gewoon rustig door.

Maar laten we het anders brengen, als je Google vervangt met MS... MS laat honderden miljoenen apparaten lekker hangen met outdated software, je snapt zelf dat dan de wereld te klein is en men massaal MS gaat afbranden. (want ook MS bouwt zijn PC's zelf niet, dat doen de OEMs en die stoppen die krengen vol met bloatware, absoluut geen hol anders dan smartphones).

Vreemd genoeg laat Google (kan moeilijk doen over OEMs wat je wilt, het is en blijft Google's OS) de halve wereld in de sop gaarkoken en mensen verdedigen het standpunt? Het is gewoon Google's schuld dat hun pas met Android 5 en 6 eens serieus naar het OS kijken en het OS eindelijk eens volwassen maken. Er is geen excuus om jarenlang in een Windows 9x achtige wereld te leven, volgend mij waren we dat security-loosheid al voorbij in de jaren 90.

2 dezelfde actie hoeft helemaal niet hetzelfde commentaar op te leveren!

Google heeft mij nooit wat beloofd, dus hoe kan ik nou iets verwachten van Google?

MS daarentegen doet wel steeds beloftes over hun OS en devices (die niet van hun zelf hoeven te zijn) en moet die dan ook waar maken om te ontkomen aan commentaar

(kan moeilijk doen over OEMs wat je wilt, het is en blijft Google's OS)

Dat is dus niet waar. Dat is de perceptie, maar niet de realiteit.

Het OS kan prima geupdate worden zoals je beschrijft en technisch gezien is je verhaal dan ook onjuist. Ik heb in minder dan 3 maanden al 2 firmware updates OTA gehad. Niet van Google. Wel van Blackberry (de nieuwe Priv draait op Android).

Je zou kunnen beargumenteren dat Google dit had kunnen zien aankomen en had moeten voorkomen, maar de verantwoordelijkheid blijft bij het bedrijf liggen waar je de phone van koopt.

Het idee (van Android) was altijd dat de handset manufacturers (uit de OHA) de vrijheid kregen om op verschillende manieren de Android source te gebruiken en dat Google zou werken aan die source. Dat het gros van ze gekozen heeft om bar weinig geld en tijd aan security updates voor hun devices te besteden en tegelijkertijd custom ROMs op allerlei vlakken tegen te werken ligt echt bij hen. Blackberry doet het vooralsnog in ieder geval anders.

Voor mij zit er geen verschil in Desktop of Smartphone OS. Google heeft willens en wetens een antiek opgebouwd OS (Android 2-4 waren amper Windows 9x waardig).

Met Windows en Linux kan je ook de gehele GUI vervangen, een ton eigen unieke troep toevoegen zodat het voor geen greintje meer op het orgineel lijkt of zo werkt, maar de OSen kunnen nog wel gewoon geupdate worden.

Als zo'n beetje elk ander OS dat probleem in de jaren 90 al opgelost heeft, waarom komt Android daar nu tegen Android 6, in 2015-2015 pas mee. Dat is gewoon laksheid van Google, weinig interesse of kennis van het bouwen van het OS en het vertikken hulp te vragen bij andere OS bouwers omdat ze het zelf "beter weten".

Met Windows [...] kan je ook de gehele GUI vervangen

Wat een onzin. Heb je een Youtube-linkje of een setje screenshots van iemand die eenvoudig de gehele GUI in een recente Windows-versie heeft vervangen?

Haast je niet.

https://en.wikipedia.org/...native_shells_for_Windows

Zijn er nog een paar, bb4win is 1 die ik in het verleden gebruikt heb. Werkt nog steeds voor Windows 10 (alleen beetje buggy, extra taakbalk op ander scherm blijft zichtbaar, steam doet vaag... voor de rest doet het het nog)

Bij BB4Win kun je explorer.exe uitschakelen en Windows gebruiken zonder gebruik te maken van de ingebakken GUI functionaliteit. Geen persoonlijke ervaring met de andere GUI vervangers.

[Reactie gewijzigd door batjes op 2 februari 2016 15:46]

Een shell is niet hetzelfde als 'de gehele GUI'.

Het equivalent in Android is de launcher (die je overigens nog veel makkelijker en robuuster kan vervangen dan in Windows of Linux).

Ze vervangen de complete gui, met bb4win kom je geen enkel Windows gui element meer tegen tenzij je het er zo na thematiseert of explorer er naast laat draaien en zo de elementen oproept.

Hele GUI alleen vervangen is niet zo moeilijk, windowblinds of talloze andere applicaties toveren het zo om in Gnome of whatever binnen explorer, wou aangeven dat dat ook los van explorer.exe kan net zoals je op Linux KDE/Gnome en anderen hebt.

Er is gewoon een platform voor om dit aan te melden. Als Google zelf ook fouten ontdekt bij bijvoorbeeld Apple, dan melden ze dat ook netjes.

Maar de Linux kernel is niet vaan Google. De bug is op de juiste plaats gemeld en is door de juiste mensen gepatched. Als je Google moet gaan waarschuwen (lezen zij de kernel mailing list misschien niet?) moet je dan ook elke kernel maintainer van elke linux distributie gaan opsporen? En moet men dan wachten met het publiceren van details totdat elke distributie is bijgewerkt?

Je mag aannemen dat ze die lezen, maar als die onderzoekers zelf al met Android aankomen, dan mag je er toch ook vanuit gaan dat ze Google even op de hoogte stellen. Die hebben een aparte divisie hiervoor, Project Zero. Hadden ze best even een mailtje kunnen sturen.

[...]

Ja, no offense, maar contact opnemen met Google is niet bepaald makkelijk en zoals hierboven al vermeld wordt, het kan maanden duren voor je een reactie krijgt.

Mijn persoonlijke ervaring is anders, meestal krijg ik binnen een paar uur antwoord.

Wellicht is het handiger als potentiële misbruikers van het lek gedemotiveerd worden om dit te proberen? Waarom zou het meer dan 66% zijn? De meeste China telefoons (80% van de mobile markt in China) draait nog 4.4

[Reactie gewijzigd door djwice op 21 januari 2016 22:43]

kon je maar een apt-get update && upgrade uitvoeren op je android [..] wie weet wordt het ooit nog iets met security van dat systeempje

niet eerst het Android-team hebben benaderd voordat zij het lek publiceerden
weet niet of men dit in prakijk zelf heeft ervaren, maar contact met google / android ... reken op minimaal 8 weken voordat er reactie komt (mijn ervaring met dit logge bedrijf)

kon je maar een apt-get update && upgrade uitvoeren op je android [..] wie weet wordt het ooit nog iets met security van dat systeempje

Muah, aangezien je met het lek root access moet kunnen krijgen moet dat volgens mij niet eens onmogelijk zijn XD. (Jaja, reality check apt-get op android aan de gang krijgen is vast ook niet echt makkelijk)

Buiten dat is het een kernel bug, je kunt niet zomaar even de kernel updaten met een apt-get update. Je zal de kernelsource moeten hebben van de telefoonfabrikant om de juiste drivers e.d. weer mee te kunnen compilen en dus vanaf source de kenrel weer op moeten bouwen.

Was het niet zo dat Android terug was op een standaard Linux kernel waarmee het dus weer wel zou moeten kunnnen? (ik kan er naast zitten)

dpkg (systeem achter apt-get) is geen onderdeel van de kernel

Je kan de kernel vervangen dat is het punt niet. Maar je hebt ook de drivers voor bijvoorbeeld de radio-modules nodig anders kan je niet meer bellen. En die zijn helaas vaak niet open source.

Maar ook niet ketsbaar voor het lek in kwestie

apt-get op android aan de gang krijgen is vast ook niet echt makkelijk

Geen idee. Jailbreaks voor iOS hadden in ieder geval gewoon apt-get geïntegreerd.

Had ooit de hoop dat we met maemo die richting uitgingen (en Jolla zal het ook wel niet redden) .. maar helaas. Gevalletje Betamax VHS vrees ik.

Meestal zijn de security teams een stuk bereikbaarder, als ze Kees Cook een linux security specialist van Google direct hadden gemaild dan was het intern ongetwijfeld snel doorgezet geweest.

Aan de andere kant is het een generieke kernel bug en niet specifiek voor Android.
Belangrijkste reden dat het voor android wat grotere gevolgen heeft is dat patches zich niet makkelijk laten uitrollen op dat platform.

Wellicht speelt ook nog mee dat security research tegenwoordig big business is. Marketing technisch wil je graag dat jouw bug zo veel mogelijk publiciteit krijgt en dus de tam tam zo vaak en hard mogelijk beroeren (en een catchy naam verzinnen, wat in dit geval dan nog niet is gebeurd lijkt het). Stil melden, impact goed inschatten is allemaal niet in het belang van deze mensen helaas.

[Reactie gewijzigd door gekkie op 21 januari 2016 12:43]

heb slechts ervaring met 1 toestel daarmee; N900 - man o man, wat een prachtig apparaat.
Er is trouwens een duits bedrijf wat begonnen is om de N900 om te katten en upgraden; http://neo900.org/#features

Ik vond hem qua model wat log ... zat te wachten op de op volger, maar toen werd al duidelijk dat intel de handdoek al weer in de ring ging gooien.

Een juiste onderwerpregel in een mail naar de juiste persoon moet wel zorgen voor een snelle reactie lijkt mij.

En over dat apt-get update. Dat zou echt een droom zijn die te mooi klinkt om waar te maken.
Denk eerder dat het Ubuntu touch OS hier eerder mee gaat werken dan Android

als je dan geupdate had naar een nieuwere versie had je dus onbewust een kwetsbaarheid geupdate...

Gewoon allemaal iets minder paniekerig doen en gewoon accepteren dat dit nou eenmaal gebeurd.
Zoals je ziet is nieuwer niet altijd beter en had je met 3,7 geen problemen en met een nieuwere 3,8 had je een kwetsbaarheid...

Ik update zelf alleen als ik er qua functies op vooruit ga ik maak me niet zo druk over al dit soort dingen die nog geen 0.5% van de wereldbevolking zal treffen en van degene die wel getroffen worden heeft 90% apps gesideload of andere meuk met zijn toestel uitgehaald.

Maar uiteindelijk krijg jij wel een reactie maar die bedrijf melde niks groot verschil lijkt mij.

voor niemand waar ik 8 weken wacht op reactie, naar week niets vernomen; jammer, andere partij

Dit bericht ook al geplaatst bij het vorige artikel.

Android

• 4.4 Kit Kat 3.10
• 5.x Lollipop 3.16.1
• 6.0 Marshmallow 3.18.10

Linux Distro's

• Red Hat Enterprise Linux 7
• CentOS Linux 7
• Scientific Linux 7
• Debian Linux stable 8.x (jessie)
• Debian Linux testing 9.x (stretch)
• SUSE Linux Enterprise Desktop 12
• SUSE Linux Enterprise Desktop 12 SP1
• SUSE Linux Enterprise Server 12
• SUSE Linux Enterprise Server 12 SP1
• SUSE Linux Enterprise Workstation Extension 12
• SUSE Linux Enterprise Workstation Extension 12 SP1
• Ubuntu Linux 14.04 LTS (Trusty Tahr)
• Ubuntu Linux 15.04 (Vivid Vervet)
• Ubuntu Linux 15.10 (Wily Werewolf)
• Opensuse Linux LEAP and version 13.2

Wellicht een klein overzicht van de mogelijk getroffen android versies enof Linux distros. Houdt er hierbij rekening mee dat de kernel volledig los staat van android. In mijn geval (Samsung Galaxy Note 2) is de combinatie 4.4.2 en 3.0.31

Ondanks dat de bug al sinds 2012 aanwezig is in de kernel betekent dit niet dat deze aanwezig is op system sinds 2012.

Bronnen:
http://android.stackexchange.com/questions/51651/which-android-runs-which-linux-kernel
http://www.cyberciti.biz/faq/linux-cve-2016-0728-0-day-local-privilege-escalation-vulnerability-fix/

Ik heb hier toch echt 5.0 met 3.4 dus je lijstje klopt niet helemaal.

Dat komt door de verschillende fabrikanten, die nog wel eens een oudere kernel versie gebruiken dan Google.

Dit lijstje is alleen voor stock android. Meeste fabrikanten lopen achter met hun linux kernels.

Het staat ook in de tekst eronder: "Houdt er hierbij rekening mee dat de kernel volledig los staat van android. In mijn geval (Samsung Galaxy Note 2) is de combinatie 4.4.2 en 3.0.31"

De disclaimer valt niet zo op want staat pas na een hele lijst linux distro's.

Wat ik persoonlijk zelf niet snap is dat hier word gezegd dat fabrikanten updates for hun eigen telefoons moeten maken omdat zei de hardware hebben uitgekozen etc.

Maar nu mijn vergelijking:
Windows werkt toch ook op iedere configuratie waarom kan dit niet bij android? Dit is mij onduidelijk.

Windows werkt toch ook op iedere configuratie

Is er nog een Windows Phone bouwer buiten Microsoft (Nokia) zelf eigenlijk ?

Niet dat ik weet of dat nu nog is. Eerder wel zoals htc (htc hd2) deed dit ook. Maar het ging mij eigenlijk alleen om de pc/laptop kant.

Windows Mobile werkt maar op een beperkt aantal hardware configuraties. Windows voor desktop werkt inderdaad op praktisch alle hardware, maar telefoons werken compleet anders dan PCs. Het is dus onvergelijkbaar

Ludwig stelt ook teleurgesteld te zijn dat de ontdekkers van de bug, Perception Point, niet eerst het Android-team hebben benaderd voordat zij het lek publiceerden

Dat heet koekje van eigen deeg.

Als meneer Ludwig vindt dat 66% te hoog is dan is het niet meer dan logisch dat je met betere waarde komt die volgens jou wel klopt, maar dat laat ie nu na.
Overigens betrekt hij alles zo lijkt het alleen maar op de Nexus toestellen, terwijl toch meer Android zijn dan de Nexus. Dit is pure damage control, meer niet.

[Reactie gewijzigd door Vexxon op 21 januari 2016 13:10]

Het is maximaal 36.1%. Versies voor 4.4 maakten geen gebruik van kernel 3.8 of hoger, en in 5.0 en hoger zit SELinux in de weg. Blijft enkel 4.4 over.

[Reactie gewijzigd door Johan9711 op 21 januari 2016 13:14]

Dat zijn er dan nog steeds miljoenen toestellen. Het maakt het probleem mijns inziens niet veel minder ernstig.

Ik schat is dat het in werkelijkheid om misschien 10% van die de Android 4.4 toestellen gaat, misschien nog wel minder. Verreweg de meeste Android 4.4 toestellen draaien een ouder kernel dan de Google builds.

Dat zijn er dan nog steeds miljoenen toestellen. Het maakt het probleem mijns inziens niet veel minder ernstig.

Dus als er maar 1 miljoen Android toestellen waren verkocht waarvan 36% of 66% lek zou zijn was het wel minder erg?

1% van 1,5 miljard is al 15 miljoen dus aan miljoenen zit je toch wel, zelfs als er 0.13% last had heb je het al over miljoenen...

Alleen Android 4.4 is kwetsbaar. Als de versies met SELinux niet kwetsbaar zijn, heeft alleen 4.4 kernel 3.8 of hoger. Dan gaat het dus om 36.1% van de devices, en niet 66%.
Komt nog bij dat niet alle 4.4 devices de kwetsbare code schijnen te hebben. (omdat de fabrikanten vaak oude kernels gebruiken)

bron:
http://developer.android.com/about/dashboards/index.html en https://en.wikipedia.org/wiki/Android_version_history
http://android.stackexcha...d-runs-which-linux-kernel

[Reactie gewijzigd door Johan9711 op 21 januari 2016 13:30]

en dan nog veel minder want vele (ik denk zelf meer dan 90%) van de android toestellen die 4.4 nog draaien hebben een lagere kernel

ik met mijn S4 die al wel op 5.0.1 zit heeft nog maar 3.4 als kernel...

Inderdaad, mijn Huawei P6 draait ook nog 3.0.8, dus is ook niet kwetsbaar.

Ludwig stelt ook teleurgesteld te zijn dat de ontdekkers van de bug, Perception Point, niet eerst het Android-team hebben benaderd voordat zij het lek publiceerden.

De pot verwijt de ketel? Kom op, Google mag dan wel zelf contact op nemen met ontwikkelaars, maar zij smijten ook gewoon een proof of concept online als die 90 dagen verstreken zijn, zelfs als ze weten dat een patch al voor 2 dagen later gepland staat. Daarbij gaat het om een bug in de Linux kernel, waarom zou die bij Google moeten worden gerapporteerd?

Daarbij smijt Google ook exploits de wereld in, terwijl ze weten dat binnen korte tijd een update voor het probleem gepland staat.

Google vind het geen 66% maar een actuele schatting geven ze dan weer niet. Beetje jammer.
Hoop wel dat deze update snel opgepakt ook door fabrikanten. Ook voor "oudere" telefoons.

Er staat letterlijk in de tekst dat alles van 5.0 hoger SELunix heeft en dus niet kwetsbaar is, oudere toestellen of uberhaupt toestellen met kernel .8.0 ook niet, dus feitelijk blijft alleen een klein deel van de 4.4 androids over. Dus ja, het is significant minder (10% maybe).

Lekker traag update beleid als je moet wachten tot 1 maart
En dan andere bedrijven enkele weken geven met als dreigement alles online te gooien.
Zou de concurentq van google nu ook wel even kunnen doen.