Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 88 reacties
Submitter: Nanax

Android 4.4 is nog steeds kwetsbaar voor malware via een 'master key vulnerability'. Door de kwetsbaarheid in het veiligheidsmodel van Android kunnen kwaadwillenden code verpakken in apk-bestanden zonder dat de cryptografische handtekening wijzigt.

In juli maakte de firma Bluebox bekend dat het mogelijk is om bij vrijwel alle Android-versies code in apk-bestanden te wijzigen zonder dat de handtekening verandert. Daardoor lijkt het alsof de geïnfecteerde app niet gewijzigd is. De beveiligingsfout is sinds Android 1.6 aanwezig en volgens Bluebox van toepassing op 99 procent van alle Android-apparaten.

Google wist het beveiligingsgat in Android 4.3 Jelly Bean te dichten. Ook bracht de zoekgigant wijzigingen aan in zijn Play-platform waardoor gemanipuleerde apk-bestanden gedetecteerd zouden worden. Het blijkt echter, zo meldt de website Security Affairs, dat het probleem met de master key-kwetsbaarheid opnieuw in het onlangs uitgebrachte Android 4.4 aanwezig is.

Via een eenvoudig Python-script zou de kwetsbaarheid in de controle van apk-bestanden gebruikt kunnen worden. Hierdoor kan via een gemanipuleerd apk-bestand volledige toegang tot het Android-besturingssysteem kan worden verkregen.

Ondanks de kwetsbaarheid is de impact vooralsnog beperkt. In Google Play zijn nog geen apps gevonden die de bug benutten. Het risico bestaat daarom vooral voor gebruikers die handmatig apk's installeren.

Update, 19:00: Beveiligingsonderzoeker Joshua J. Drake claimt dat door middel van een patch het gat is gedicht in de AOSP-code van Android 4.4.

Gerelateerde content

Alle gerelateerde content (23)
Moderatie-faq Wijzig weergave

Reacties (88)

Zeg, als een apk op deze manier volledige controle kan krijgen over het systeem, is dit dan geen manier om een APK te maken met "root" mogelijkheden? Of sla ik de plank nu volledig mis? :?

Edit:
Om zo dus een soort van "root"-kit te maken ipv allerlij truukjes halen en zo de mogelijkheid dat je je mobiel brickt?

[Reactie gewijzigd door Lightmanone1984 op 4 november 2013 19:58]

Een toetsenbord app patchen. Die kan alle aanslagen doorloggen naar je server. Creditcardgegevens, pincodes, etc...
En daar schuilt 1 van de twee zaken die het probleem van malware op Android mogelijk maken. Namelijk een gebruiker die de gevraagde permissies niet leest. Dit, in combinatie met een vrij beleid waar gebruikers alle componenten van kunnen aanpassen/updaten via apps die al dan niet via de Google Play store moeten komen, maakt het platform zo kwetsbaar.

Bij iOS is het simpel; een toetsenbord installeren kan niet.
Bij Android kan je dat wel. Ben je dan zo stom om geen 2 keer na te denken wanneer een toetsenbord of wallpaper internet connectie nodig heeft en 101 andere zaken, dan moet je je afvragen of de gebruiker niet het grootste probleem is.

Dat dit uberhaupt kan bij Android is niet iets wat het platform verweten moet worden, dit is een onderdeel of eigenschap van het platform by design. Al zie je natuurlijk wel dat Android zich by default meer op de "domme" consument begint te richten. Zo is het bij de recente versies al niet meer zo eenvoudig om apps buiten de store te installeren, aangezien die setting onder de developer options zit, die je niet in 1 2 3 kan enablen (hoewel het natuurlijk nog steeds kinderlijk eenvoudig is - Android heeft heus niet de rug gekeerd naar de developer/rom community, ondanks andere berichten)
De permissies van android vind ik ook voor geavanceerde gebruikers erg raar, ze gaan wel heel erg uit van de goedheid van app developers. De meeste permissies zijn alles of niets: facebook vraagt toestemming om toegang tot je adresboek te krijgen bij installatie, niet bij benaderen van je adresboek. Ook is er geen afzonderlijke permissie voor bijvoorbeeld navigatie-apps om de details van 1 contact op te halen.

Ik heb er geen enkel probleem mee dat een app mij kan vragen iemand uit mijn adresboek op te zoeken, een event in mijn kalender weg te schrijven, of dat soort dingen. Maar ik vind het wel een probleem dat apps mijn hele adreslijst en kalender leeg kunnen plukken.
Doet me denken aan de root exploit in Gingerbread (2.3)

O.a. een apk genaamd gingerbreak zorgde voor root met een druk op de knop.
Een soort one click root dus.

Iets vergelijkbaars is echter nu niet mogelijk volgens mij.

[Reactie gewijzigd door Lamba op 4 november 2013 20:32]

Gingerbreak en andere One-Click-Root's werken overigens wel iets anders. Die maken weleswaar gebruik van kwetsbaarheden in de Linux kernel, maar behalve die knop wordt er onder de motorkap nog het een en ander gedaan.

Vaak wordt er een bestand naar de tmp map geschreven en wordt dat bestand executie rechten gegeven. Dan kan dit bestand uitgevoerd worden en zo het systeem beÔnvloeden dan het superuser (of root) toegang krijgt. Hierdoor kan het zichzelf dan kopiŽren naar bijvoorbeeld de bin map, zodat het bestand als globaal uitgevoerd kan worden.

In feite dus inderdaad een soort van virus of rootkit. Echter wel een vriendelijke, die ook eigenlijk altijd te verwijderen is.
Ik ben al een behoorlijke tijd fan van Android, alleen de laatste tijd zijn er wel een aantal redelijk gevaarlijke bugs gevonden. Gelukkig installeer ik niet zoveel apk's, maar het blijft slordig. Zeker bij een OS dat zoveel gebruikt wordt.
Dat probleem had je in de jaren '90 en begin 2000 ook bij Windows, allemaal virussen, vooral omdat het platform zoveel gebruikt werd. Dan is het namelijk als malware ontwikkelaar veel aantrekkelijker om een virus te ontwikkelen.

In de afgelopen jaren zie je ook steeds meer malware voor zowel OS X als Java verschijnen. Mac OS X begint een logischer slachtoffer te worden, omdat het ook steeds meer gebruikt wordt. En Java is natuurlijk vooral interessant omdat het op alle drie de desktop besturingssystemen draait, waarbij het zowat overal geÔnstalleerd was en soms nog is.

Nu krijgen we een stormloop op Android, maar mocht over zeg, 10 jaar, een ander systeem populairder worden, dan zal dat systeem ook weer een groter slachtoffer gaan worden voor malware schrijvers. Het is dus in feite gewoon marktwerking, waar malafide programmeurs lekker op inspelen.
Het is waar dat de populariteit van een systeem een factor is in hoeveel virussen er voor geschreven worden. Waar ik me echter aan erger is dat dit te pas en te onpas wordt gebruikt als soort van excuus: als een systeem relatief veilig is, dan is dat omdat het niet populair is. Als een systeem brak is, dan komt dat doordat het populair is.

Het is wel degelijk zo dat bepaalde systemen veiliger zijn dan anderen, geheel onafhankelijk van hun populariteit. Zo zijn de meeste Unix/Linux klonen wanneer goed toegepast veilig, omdat veiligheid centraal staat in het OS. Zo is een strak app store model veiliger dan een liberaal beleid.

Systemen, of eco-systemen, zijn dus inherent veilig of onveilig door ontwerpkeuzes. De populariteit van een systeem kan de consequenties uitvergroten of juist niet, maar de populariteit zorgt niet voor de (on)veiligheid.
Het klopt niet helemaal wat je zegt. Er was een kleine oprisping toen er via Java veel OSX machines werden besmet. Dit werd echter verholpen in 2012 en de verwachting dan er veel meer malware in 2013 zou verschijnen bleef uit.
Daarnaast heeft iOS wel een groot marktaandeel 20% tegen 70% Android. Toch is 99% van de malware gericht op Android. De rest op Symbian.
http://www.securelist.com/en/analysis/204792255/

Edit: aangepast na comment van horizon.

[Reactie gewijzigd door SoloH op 5 november 2013 00:05]

Dat marktaandeel 28 tov 35 klopt volgens mij niet.
Je hebt gelijk, Android is sterk gestegen naar 70% en iOS 20% begin dit jaar. Dus dat is 3,5 x zoveel. Dat staat dus nog steeds niet tot de verhouding malware.

Daarbij was het marktaandeel van iOS jarenlang groter.

[Reactie gewijzigd door SoloH op 5 november 2013 00:07]

Ja idd het is kommer en kwel op zowel Linux als vooral ook OSX! bah :( O nee, wacht even dat is helemaal niet zo :+

Zou het misschien zo zijn dat malware schrijven gewoon een business model is geworden en ze gewoon voor de makkelijkste manier gaan, dat het platform in kwestie enorm groot is en de eindgebruiker vaak nogal clueless helpt wel maar is niet bepalend. Feit is wel dat zowel Linux als OSC groot genoeg zijn om er geld mee te verdienen als malware boer, en anders is er nog de pats factor: HET succesvolle virus op 1 van die platformen versus weer een succesvol virus voor dat andere platform ;)

Zal niet zeggen dat Android niet groot genoeg is, maar vooralsnog is het niet zo bar als in Windows desktop land. Laten we hopen dat dat zo blijft!

Persoonlijk ben ik van mening dat mentaliteit alles is. Kijk naar patch tuesday (tussendoor moet je Windows geloof ik maar niet gebruiken als ik de security bedrijven moet geloven) en de nog steeds default admin user op windows (heb je een superieur user systeem, gooi je dat gelijk het raam uit!) versus de soms draconische maatregelen op Linux zonder dat er ook maar sprake is van een probleem en MacOSX dat stilletjes gaat richting een trusted platform met het afdwingen van signed software, wederom zonder dat er echt sprake is van een probleem.
Je laatste zin "omdat het zo'n groot OS is". Dat is het nu net. Android is het grootste platform dus er valt extreem veel te halen.

https://www.google.nl/url...h5Q&bvm=bv.55819444,d.Yms

Ontwikkelaars van dit soort malware zullen dus wel meer tijd in malware voor Android steken dan voor andere OS'en.
Tjah, alsof Windows Phone of iOS zoveel 'veiliger' is, what has been made by humans, can be cracked by humans.. behalve 2048bit, maar hoe lang zal het nog duren voor er iemand een speciaal script heeft dat dat ook eenvoudig kan decrypten :p
Ja, het gaat over dit gat en die hebben WP en iOS niet. Die besturingssystemen zijn ook zozeer beperkt dat je normaal geen pakketten van buiten de store kan installeren, dus dan heb je dit probleem niet. Inderdaad, wat door een mens gemaakt is, kan door een mens gekraakt worden, maar zo kan je wel redeneren dat je niets moet beveiligen, het kan namelijk toch wel gekraakt worden.
uhm erverschijnt toch af en toe echt wel malware in de iOS store, gelukkig wordt dit wel snel aangepakt, maar het is dus wel mogelijk..
ik weet nog dat ik mijn ipod touch een paar jaar geleden gejailbreaked heb door een pdf te downloaden. Ieder OS heeft af en toe zo z'n foutjes en het OS met de meeste gebruikers is het meeste de pineut, net als windows en linux/mac os x.
In een open systeem ontdekt men theoretisch gezien de meeste bugs en zullen die ook vaker misbruikt worden.
Akkoord, alles wat gemaakt is door mensen, kan gekraakt worden door mensen. Maar daarom mag het nog wel moeite kosten :)

Na de bug van Juli lijkt het mij dat ze flink naar de beveiliging hebben gekeken. Dat zullen zo ook vast gedaan hebben, maar als er nu weer een 'bug' gevonden is, die vrijwel hetzelfde werkt, zal ik me als ik Google toch even achter de oren gaan krabben.
Omdat het helemaal niet zo waar is als jij zegt. Lees mijn reactie eens :)
Van dit soort ontzettend belangrijke dingen (hallo identity theft bijv.) verwacht je toch dat het goed wordt getest, zeker nadat het probleem al eerder is voorgekomen.
lekker nieuws dit:

en android is al zo lekker veilig:
http://op-co.de/blog/posts/android_ssl_downgrade/

je zou zeggen dat ze daar bij google ook weten wat regressietesten zijn..

[Reactie gewijzigd door BasieP op 4 november 2013 20:39]

Zijn er servers die uberhaupt nog iets met RC4 ondersteunen? Die server ondersteund dan waarschijnlijk ook nog SSLv2. Met andere woorden je komt al snel uit op AES128-SHA bij Android. Iedere sysadmin die een server runned die serieus RC4-MD5 ondersteund is echt gek...

Daarnaast gebruik ik in me Android apps gewoon Spongy Castle (aangepaste versie van Bouncy Castle voor Android). TLSv1.2, cipher list aangepast zodat er geen weak ciphers gebruikt kunnen worden en een eigen X509TrustManager implementatie zodat enkel mijn server certificaat geaccepteerd word en niet de volledige lijst van CA's.

Als je App communiceert met een server ben je als programmeur zelf verantwoordelijk voor die beveiliging.
De tip om echt je eigen certificaat te controleren is een hele goede. In de apps die ik bekeken heb gaat dat vaak mis.

RC4 was een tijdje (na de ontdekking van BEAST en voordat die recente zwakte in RC4 bekend werd) een relatief goede keuze. Voor forward secrecy werd het zelfs gebruikt door o.a. Google (RC4-SHA dacht ik).

De Qualys SSL check is trouwens een mooie tool om de instellingen mee te evalueren. Vooral als je forward secrecy bij oudere browsers (bv IE6, dat standaard niet meer kan verbinden bij TLS 1.1 afaik) wilt instellen wordt het een lastige puzzel.

edit: laat, moe, typo

[Reactie gewijzigd door ANdrode op 5 november 2013 00:32]

Ja, er zijn nog heel veel servers die RC4 ondersteunen. Omdat block ciphers in CBC-modus vatbaar zijn voor de BEAST-aanval en RC4 de enige in SSL gestandaardiseerde stream cipher is had die afgelopen jaar de voorkeur. Ja, Google zette zelf tot heel recent (en met hen vele anderen) RC4 in om hun SSL-verkeer te encrypten.

Daarom is het fout dat Google deze Java-standaard zo klakkeloos over heeft genomen.
Ik heb laatst een keer een artikel gelezen(weet even niet waar, dus heb geen bron) waarin stond dat nog best wel veel servers RC4 ondersteunen, en nog erger, forceren.
De wijzigingen aan de default cyphers waar je naar linked zijn wijzigingen waardoor een Android app zich op crypto gebied precies zo gedraagt als normale Java software :).

Het is in ieder geval in mijn ogen geen argument tegen de veiligheid van Android. Of het handig is om de (Java) standaard te volgen in plaats van een andere volgorde qua cyphers te kiezen laat ik open.

Gelukkig is de cypher die je echt gebruikt een overeenkomst tussen de client en server. Binnen bepaalde grenzen (bv servers die verbinding verbreken bij een TLS 1.1 handshake, zoals veel diensten van de Universiteit Twente...) zorgt het overleg tussen client en server ervoor dat er een goede keuze gemaakt wordt. Beide kanten verwerpen hele gekke keuzes.

[Reactie gewijzigd door ANdrode op 4 november 2013 21:52]

@BasieP: je reaktie is behoorlijk off-topic. Het artikel van Tweakers gaat helemaal niet over de beveliging van webservers, het gaat alleen maar over de beveliging van de APK bestanden zelf..

Het artikel dat jij aanhaalt gaat erover dat Java meer prioriteit heeft gegeven aan RC4 omdat dit als enige bestand is tegen de BEAST aanval (https://community.qualys....g-the-beast-attack-on-tls). Je leest het goed: als enige

@JUDGExKTF dus RC4 is nog helemaal niet zo'n slechte keuze. De enige echte oplossing is TLSv1.2
@DCK ik zie nu pas dat je hetzelfde zegt.... 8)7

[Reactie gewijzigd door [Yellow] op 5 november 2013 13:40]

Ja daarom als ik het artikel mag geloven staan deze Apps met de bug niet in de playstore. Gebruikers downloaden de APK buiten de playstore om.

Bijv voor iemand die 1 euro teveel vind voor een app, gaat naar piratebay of noem het maar op. Download de APK daar gratis incl de bug en installeert het op zijn telefoon.

Dan heeft Google de keuze om het niet meer mogelijk te maken om Apps van buitenaf te installeren (waarbij mensen gaan huilen)
Of ze maken 1 of andere check die alsnog Apps buiten de playstore controlleert
Of ze zetten in de voorwaarde dat het op risico van de gebruiker is ( maar dan doen ze al.... )

Deze fout ligt dus vooralsnog bij de gebruiker en niet bij Google.

Als ik een virus download op mijn Windows pc via via dan kan ik niet MS aansprakelijk stellen, het was mijn keuze om het via via te doen
Is zeker iemand de fix vergeten in te checken?
flamebait is dat jij niet bereid bent tot een discussie.
niet logisch? hallo? volgens mij heb jij dit mis ik vind serieus dat door dit soort dingen je gegevens op straat komt. daar gaat het artikel ook over. waarom wil je anders een lek dichten als je het toch geen issue vind.
lijkt wel rusland hier. kritiek en meteen censuur.
Wat ik me afvraag; schrijven ze heel kitkat opnieuw? Anders zou zoiets niet voor moeten komen, 4.4 is toch gebaseerd op 4.3?
Nee, een nieuwe Android versie wordt gebouwd op een oudere Android versie. Echter begint Google al een paar maanden van te voren aan een nieuwe versie te werken. Het zou dus zomaar kunnen zijn, en dat lijkt mij niet geheel onlogisch, dat ze vergeten zijn de nieuwe Jelly Bean (4.3) fixes toe te passen in KitKat (4.4). Zulke problemen komen namelijk weleens vaker voor.
Of het gaat hier om een andere bug in een ander deel van het OS die dit ook mogelijk maakt, ik weet niet of het mogelijk is maar Android zal toch niet op maar een pijler steunen?
Wat ik me afvraag; schrijven ze heel kitkat opnieuw? Anders zou zoiets niet voor moeten komen, 4.4 is toch gebaseerd op 4.3?
Het zal wel niet helemaal opnieuw zijn geschreven. Misschien is een deel van de oudere code hergebruikt, misschien is het wel een nieuwe bug die hetzelfde gevolg heeft. Wie zal het zeggen.
Was dit niet redelijk simpel te patchen? Waarom is dat niet gedaan?
"Ondanks de kwetsbaarheid is de impact vooralsnog beperkt."

Daarom dus. Als je de officiele Play store gebruikt heb je er geen last van. Alleen als je .apk's installeert die elders vandaan komen loop je risico.

Voor Google dus koren op de molen, want dan kunnen ze mensen wijzen op het belang van downloaden uit hun appstore.

Totdat er natuurlijk echt een keer stront aan de knikker is en er een app doorglipt en in de Play store terecht komt...

[Reactie gewijzigd door Morrar op 4 november 2013 20:11]

"Voor Google dus koren op de molen"
Nou nee, Google streeft de laatste tijd steeds meer naar betere beveiliging. Zoals het inbouwen van een (beperkte) virusscanner die gedownloade apps scant in Android 4.3. Want Google is bang dat consumenten overstappen naar iOS, of Windows Phone die toch wat veiliger zijn dan Android.

Consumenten beginnen zich steeds meer te verdiepen in beveiliging en malware. Consumenten zeggen minder snel "Het doet het toch?", maar "Wat doet dat virus?". De smartphone is iets persoonlijks geworden. En dat moet goed beveiligd zijn. Zelfs als consumenten downloaden buiten de Play Store.

[Reactie gewijzigd door 12345dan op 4 november 2013 20:26]

En toch valt het redelijk mee met hoeveel veiliger het is. De impact van malware op Android is bizar laag. Dat het merendeel van de malware *geschreven is voor Android*, wat ook logisch is gezien het de absolute marktleider is, betekent nog niet dat ook alle telefoons hier meteen last van hebben.

Dat is echt een heeeeeeel erg klein aandeel.
Ik heb net even gekeken naar het aantal geÔnfecteerde mobiele Android apparaten dat waren er in het eerste kwartaal van 2013 32,8 miljoen, toen waren er ongeveer 900 miljoen Android apparaten. Dat zou betekenen dat 1/30 van de Android smartphones besmet is, dat is behoorlijk veel.
Heb je ook rekening gehouden met de regio waarin dit voorkomt? Blijkt voornamelijk China enzo te zijn, waarbij het vaakst besmetting via andere sites plaatsvindt, dus buiten play om.
Ik heb het artikel wat jij denk ik gebruikt hebt er eens bijgezocht.
Let op dat het hier gaat om:

1.) Alle versies van Android, ook zeer verouderde
2.) Eerste kwartaal van 2013 is gelul, 32.8 miljoen is slechts door 1 partij genoemd: en dat ging over het totaal aan (mogelijk) geinfecteerde apparaten in heel 2012... Niets eerste kwartaal 2013. :X
3.) Sommige "infecties" waren "vermoedelijke infecties", en dus niet zeker
4.) False-positives wordt met geen woord over gerept; de betrouwbaarheid van de data is niet te toetsen
5.) ... Een aantal andere security firma's schatten aan de hand van data en "upcoming numbers" dat er 'slechts' 18 miljoen Android apparaten in totaal tussen 2012 en eind 2013 potentieel geinfecteerd zullen raken met een of andere vorm van malware, veelal onschadelijk en of ze hiermee langdurige infectie bedoelen of gewoon een "oeps en weer eraf gooien" infectie. Enfin: boeit niet, laten we van het ergste uitgaan dan maar.

Dat zijn toch even wat verschilletjes met wat jij hier wil schetsen, en die *schatting* houdt in dat het 'slechts' 1.8% van alle actieve Android apparaten zou gaan bedragen... Dat is wel ff een iets ander verhaal. :) En dan nog even bedenken dat Google veel nieuwe maatregelen heeft getroffen sinds die schattingen uit 2012...

Dus ja..
Ik betwijfel of daar nog iets van overblijf als je alleen apparaten meetelt die gebruik maken van de play store (of de amazon store)
Jij hebt bewijs dat heeeeeeel erg klein is?
Buiten dat wat WhatsappHack zegt:

Hoeveel devices draaien op dit moment al Android 4.4? Er komen ongetwijfeld minor versies uit die bugs fixen.
Och een paar miljoen maar ;)
http://goo.gl/7xZ4cd
http://qz.com/131436/cont...-impenetrable-to-malware/

Enjoy.
Mensen moeten niet zo blijven hangen in het tijdbestek dat Android net uit was en wat problemen had. Tegenwoordig is er vrijwel niets over van die problemen, behalve de "onbekende bronnen" installaties, die tevens toch nog worden gecontroleerd en op meerdere manieren worden dwars gezeten als het geen goede app is. En als je voor dat type installaties kiest, of daar toe overgelaten bent als je geen GAPPS hebt dankzij je vendor of custom ROM, dan is dat toch een eigen keuze. Maar dan nog beschermt Android je op meerdere manieren...

Kortom, zelfs ALS je een malicious applicatie weet te installeren heb je alsnog minder dan 0,00001% kans dat het daadwerkelijk ook maar iets qua schade aan kan richten...
ALS je geinfecteerd wordt, en die kans is dus al bijzonder klein door alle checks en permissions, dan is het ergste wat je kan meemaken een irritante blaf notificatie in je notification balk of een random splash screen... Meer niet. Iets wat overigens ook in iOS is voorgekomen, dus wat dat betreft zijn ze duidelijk even veilig.
Geen keyloggers, geen trojans, worms, of wat dan ook kunnen zomaar door de Android defenses heen.

En ja, met zulke statistieken en zulke grote lagen qua beveiliging in Android plus de aangetoonde percentages... Hoop ik dat je hier je bewijs hebt. ;)
Het was letterlijk met een appje een minuut werk om dit te fixen. Voor die paar duizend die het Google had gekost gooien ze de naam van Android niet te grabbel. Zelfs niet als ze dan mensen kunnen wijzen op de "gevaren" van buiten de Playstore om gedownloade apps.
Jammer dat deze bug dan terugkeert. Google is ook zo bezig met Android in het algemeen waardoor ze niet diep genoeg kijken en dus deze bug laten zitten. Als ik eerlijk ben zijn de releases van de Android versies redelijk snel op elkaar gekomen. Zeker 4.1-4.3
De Jelly Bean branche heeft ongeveer anderhalf (bijna twee) jaar ontwikkeltijd gehad. Wat eigenlijk toch wel een normaal tempo is. Natuurlijk hoef je ook niet meteen te updaten wanneer er een nieuwe versie uit is.

Het grootste probleem wat nu nog speelt zijn zowel de aanpassingen van de fabrikanten en het testen daarvan, wat erg veel tijd in beslag neemt in het ontwikkelproces. Alsmede de testen door de providers, die nog weleens updates willen tegenhouden.
Het is eigenlijk voor een OS dat zo immens populair is ook niet raar dat er snel betere versies komen. Alleen is het extreem jammer dat ze zo bezig zijn geweest met nieuwe features etc dat de bugs worden vergeten (al heb ik natuurlijk geen idee hoe dat is in google land).
nieuwe features? noem mij nu eens echte nieuwe features vanaf 4.1 tot en met 4.4. Ik vind dat nog al mee (of tegen) vallen. zo veel krijg je nu niet echt, her en der wat hardware support. Maar om nu te zeggen wow ik moet nu direct zo snel mogelijk 4.3 of 4.4 hebben als je al op 4.1/2 zit..
Zou je dit probleem niet met een virusscanner oplossen? Misschien is het een idee voor google om een virusscanner ingevouwen, zoals Microsoft ook in Windows doen. Android is niet het veiligste besturingssysteem
Google heeft al een virusscanner ingebouwd vanaf 4.3. Vanaf 4.3 worden alle apps die je installeert sowieso nogmaals gescand. Daarnaast is het natuurlijk niet de bedoeling van Google dat je afwijkt van de Play Store.

Buiten dat is Android veilig genoeg te noemen. Ook het toevoegen van SELinux kernel in 4.3 en nu nog strenger in 4.4 zorgt ervoor dat het systeem toch veilig genoemd kan worden.
Volgens mij maakt die virusscanner deel uit van de Google Services (die app met het groene icoontje), en werkt het scannen van apk-bestanden voor de installatie ook bij oudere Android-versies. Ik heb het weten werken op Android 4.1 en 4.2 in elk geval. Maar het is in mei dit jaar ongeveer ingevoerd, dus iets voordat Android 4.3 verscheen.
Android niet veilig? Ik zou toch eens je bronnen nakijken: http://www.xda-developers...-safe-is-safe-in-android/
Grappig, want juist de bron voor dat artikel was de Android security Chief zelf met een niks zeggend grafiekje.
En in 4.3 en hoger zit ingebouwde virusdetectie
Een virusscanner is handig en soms onmisbaar, maar het blijft een lapmiddel. Het is nog altijd: "beter voorkomen, dan genezen." Een virusscanner is eigenlijk een extra slot op de deur.
Google scant al apps.
Er zit natuurlijk al een virus scanner in net als die van MS in Windows maar dan kopen ook veel mensen nog een anti virus software pakket van een ander gespecialiseerder bedrijf.
Voordat Google het had gefixt was het al redelijk eenvoudig "zelf" te fixen als je telefoon geroot is, namelijk met de Mater Key Dual fix (requires Xposed). Hopen echter dat Google dit zelf weer zal fixen. Ik denk dat het niet al te moeilijk moet zijn, gezien ze de bug al eens hebben gefixt. Denk dat het een meer een kwestie isdat 4.4 is gebaseerd op een versie van 4.3 waar de bug nog steeds in zat, en dat het weinig meer zal zijn van het mergen van de bugfix ervoor en dat het dan opgelost zal zijn, hopelijk voor eens en altijd :)
Alleen lijkt het momenteel onhandig om Xposed nu te installeren, aangezien er nog geen support zal zijn voor 4.4. Hierdoor kun je dus, in het slechtste geval, je telefoon soft-bricken. Niet iets waar menig mens geÔnteresseerd is :+. Waarschijnlijk zal Xposed en ook de Android code (AOSP) snel genoeg geŁpdatet worden met de juiste fix van Google.

Buiten dat draaien er nog bijzonder weinig mensen 4.4 officieel. En heeft Google dus genoeg tijd om het een en ander nog recht te breien.
Zou handig zijn voor o.a. NSA. deinstalleer een app van de Android smartphone van je doelwit op een onbewaakt moment of wanneer die het moet afgeven(misschien vliegveld?) en installeer een app met bijvoorbeeld een keylogger.
Hier wordt het verteld hoe gemakkelijk het is: nieuws: Hackers zetten Swiftkey om in keylogger voor Android
Heb in verleden ook met een Swiftkey getest met een keylogger ingebouwd(opzettelijk, proof of concept apk), waarvan de server bekend was om je keystrokes te bekijken. Virusscanners etc.. vinden het niet eens. Verder houdt droidwall het ook niet tegen.
Zodra iemand fysieke toegang tot je telefoon heeft dan is dat zeker mogelijk, overigens kan die persoon dan al direct bij je persoonlijke data.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True