Universiteit van Texas ontdekt kwetsbaarheid in lockscreen Android Lollipop

Een onderzoeker van de Universiteit van Texas in Austin heeft een methode ontdekt om een Android-lockscreen dat met een wachtwoord beveiligd is, te omzeilen. De exploit maakt gebruik van een zwakte in de camera-app en zit in Android 5.0 en later.

De Android-versies die de onderzoeker meldt als kwetsbaar zijn Android 5.0 tot Android 5.1.1 build LMY48M. In die build heeft Google het probleem opgelost. De onderzoeker demonstreert de bypass op een Nexus 4 die draait op Android 5.1.1 build LMY48I. Het maakt voor de bypass niet uit of encryptie aan staat of niet. Het is niet duidelijk of de kwetsbaarheid zich ook voordoet in de roms van andere fabrikanten. Volgens cijfers van Google draait 22% van de Android-apparaten op versie 5.0 of nieuwer. 5,1% draait op versie 5.1, maar onduidelijk is bij hoeveel van die 5.1% de kwetsbaarheid al opgelost is. Op 9 september heeft Google Android 5.1.1 build LMY48M uitgebracht. Android M, de zesde versie, lijkt niet kwetsbaar te zijn.

De bypass werkt alleen wanneer de smartphone een lockscreen met wachtwoord heeft ingesteld, en wanneer een kwaadwillende fysiek toegang heeft tot het apparaat. De onderzoeker gaat vanaf het lockscreen naar het noodoproep-venster, voert daar een aantal asterisken in, kopiëert die naar het klembord, plakt die achter de bestaande asterisken en herhaalt het proces totdat het veld volledig gevuld is met de tekens. Een ander teken kan ook gebruikt worden. Na ongeveer 11 herhalingen is het veld vol.

Daarna gaat hij terug naar de lockscreen en opent de camera. Vanaf daar wordt de notification drawer geopend en drukt de hij op het tandwieltje om naar de instellingen te navigeren. Hier wordt hij om het wachtwoord gevraagd. Als een aanvaller hier de tekens die hij op het klembord heeft staan achter elkaar blijft plakken in het wachtwoord-veld, moet op den duur de camera-app op de achtergrond vastlopen. Wanneer dat gebeurt, wordt de gebruiker als het goed is naar de homescreen gebracht en kan hij na de app drawer te openen in de instellingen komen. Daarna is hij vrij bijvoorbeeld usb debugging aan te zetten en op die manier alle gegevens en bestanden van de eigenaar buit te maken, of een malafide app te installeren.

Reacties (93)

De bug is met het volgende gefixt: https://android.googlesou.../base/+/8fba7e6%5E%21/#F0

android:maxLength="500"

Dat is het enige wat is toegevoegd om het probleem te verhelpen. Omschrijving: Prevent insanely long passwords from crashing SystemUI. Er zit nu dus een beperking op het aantal tekens dat een wachtwoord kan hebben. 500 tekens is alsnog absurd lang, maar je kan er iig geen crash mee veroorzaken omdat het aantal tekens dat je invuld ook gecapped wordt.

[Reactie gewijzigd door Hero of Time op 16 september 2015 08:14]

Dit zouden ze dan ook direct moeten doen voor het noodoproep-venster (of de dialer in het algemeen). Ik heb zojuist mijn dialer laten crashen door teveel tekens achter elkaar te blijven plakken. Meer dan 500 tekens lijkt me voor een dialer ook nogal overbodig.

Leuk als je van menu naar menu naar menu [...] naar menu wordt gegooid met tig opties. Kan je uiteindelijk niet meer verder, omdat je geen keuzes meer mag maken. Of voor bepaalde diensten waar je een nummer in moet vullen, zoals bijvoorbeeld prepaid opwaarderen via een prepaid kaart.

500 tekens is nog steeds veel, maar voor je 't weet zit je er al aan.

Als ik een telefoonnummer van 10 cijfers invul, gevolgd door een prepaid code van laten we zeggen 20 cijfers, nadat ik een belmenu van 10 stappen heb doorlopen. Dan zit ik nog maar aan 40 tekens... Laten we dat eens verdubbelen omdat ik in het menu een typfout maakte en de prepaid code verkeerd schreef, dan komen we nog niet aan de 100. Dus dat 'voor je het weet zit je er aan' zal wel meevallen :-).

Ik ben altijd wel benieuwd hoe mensen dit soort bugs ontdekken. Wie verzint het om dit veld 'vol te spammen' en de waarde te kopieren, om daarna deze waarde te gebruiken om de camera app te laten crashen, in de hoop dat je weer terug gaat naar het homescherm in plaats van het loginscherm.

De fix om een maxlength in te stellen klinkt eenvoudig, maar is uiteindelijk een pleister op de wond. Mocht je het voor elkaar krijgen op de camera app op een andere manier te laten crashen, kom je dan ook voorbij het loginscherm? Of is doet dit probleem zich alleen voor in de 'wachtwoord dialoog' die door de camera app wordt aangeroepen? Er zijn anders vast ook andere manieren om de camera app te laten crashen. Wie verzint er 1? :-)

Even voor de beeldvorming, dit zijn 500 tekens(!):
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

[Reactie gewijzigd door ReneDD op 16 september 2015 14:20]

Is dit lek er ook op toestellen die een andere camera app hebben of aangepast lock screen zoals op HTC, Samsung, LG, Huawei en alle andere niet stock versies van Android?

Geprobeerd op mijn HTC one M8 met 5.0.1, kan ook geen dingen kopieren bij noodoproep...

Geprobeerd op mijn HTC one M8 met 5.0.1, kan ook geen dingen kopieren bij noodoproep...

Ik kan dit bevestigen. Geen optie om het noodoproepnummer te kopiëren.

Bovendien gebruik ik het unlock-patroon ipv pincode en dan werkt het ook niet.

[Reactie gewijzigd door bilgy_no1 op 16 september 2015 12:43]

Ik heb de bug zojuist op mijn oneplus ons uitgeprobeerd draaiende op cyanogenmod 12.1(Android 5.1) maar is mij niet gelukt, dus ik neem aan dat dit niet voor alle merken/type mobieltjes geld

Op mijn i9505 met cm21.1 kan ik in de dealer bij een noodoproep niks kopiëren. Geen issue dus.

Conclusie is dus dat dit flink opgeblazen wordt en slechts voor een veel kleinere groep speelt!

Hier op Galaxy S5 met 5.0 is het niet mogelijk om de noodoproep telefoonnummer te kopiëren, dus valt er niets te breken (heh, een keer dat de TouchWiz skin je toch nog veiligheid bied!).

Edit: Heb wel een scherm gevonden waar ik heel veel karakters kon kopiëren en plakken (Noodoproep -> Nieuwe ICE contact (druk op die dikke +) -> contacten selecteren venster heeft zoekveld).

Het instellingen venster is ook niet bereikbaar vanaf lockscreen, dus daar valt niets te klooien.

[Reactie gewijzigd door Diamondo25 op 16 september 2015 00:37]

Op de S6 met 5.1.1 is het ook niet mogelijk...

Ik kan het niet reproduceren op mijn Moto G (2014), omdat je vanuit de camera app niet meer naar het tandwieltje kunt zonder de app te verlaten.

Binnen de camera app in mijn LG G4 is de notificatiebalk geblokkeerd wanneer het apparaat gelocked is. Dus het lijkt mij dat de meeste LG telefoons wel veilig zitten.

Bij Huwaei op Emui 3.0 werkt het niet, ik weet niet hoe dat is bij Emui 3.1

Lijkt op een behoorlijke buffer overflow......

Het is Java, en in Java krijg je niet zo snel buffer overflows. Ik denk dat het geheugen gewoon volraakt. 11x 10 tekens plakken geeft je 10 * 2^11 tekens, dat zijn 20480 tekens. Voor elk teken moet waarschijnlijk een speciaal object gemaakt worden, en op die manier kan het best wat geheugen kosten. Uiteindelijk zal de OOM killer waarschijnlijk de applicatie afsluiten.

10 * 2^11 tekens, dat zijn 20480 tekens. Voor elk teken moet waarschijnlijk een speciaal object gemaakt worden

Voor elk karakter een speciaal object?? Huh? Lijkt me zeeeeer onwaarschijnlijk. Java kent toch ook gewoon een string class? multibyte character string. Dan zit je op hoogstens op een paar Kb aan data.

Nee, dit lijkt me wel een buffer overflow.

In java zijn strings inmutable. Dus als je een string wilt aanpassen wordt er onder water een nieuwe, aangepaste, string gemaakt.

Maar dan zijn het nog steeds geen hoeveelheden geheugen waar een telefoon/os wakker van mag liggen.

Zelfs wanneer alle tussenstrings worden bij gehouden, dan kom ja alsnog niet aan een bufferoverflow. Voor de mop heb ik uitgerekend hoeveel karakters je hebt wanneer de strings niet verwijderd worden en je het 13 keer kopieert (er staat uiteindelijk dat het ongeveer 11 is.

sum_{i=0}^{13}(10*2^i)

dit zijn 163830 karakters, wat dus uitkomt op +- 0,163 MB.

Zelfs als ze elk karakter apart toevoegen en alle tussenliggende strings niet verwijderen, dan zal het waarschijnlijk niet zomaar lukken door memory overflow.

sum_{i=0}^{10*2^11}(i)

komt uit op ongeveer 209 MB (wat veel is, maar bijzonder veel minder dan in de gemiddelde telefoon. Echter als ze het 12 keer doen, dan krijg je wel al hoeveelheden waar 1GB-toestellen misschien problemen mee krijgen, dan dan krijg je al 840MB

De OOM killer sluit applicaties af, maar als ik handmatig SystemUI afsluit komt de telefoon na het herstarten ervan juist bij het lockscreen terecht.
Bij het killen van het System process wordt een soft reboot in gang gezet.

[edit]
-excuus, hier stond onzin door Huismus's post niet goed gelezen/begrepen te hebben -

Voor elk teken moet waarschijnlijk een speciaal object gemaakt worden, en op die manier kan het best wat geheugen kosten.

Onzin, een string is niets anders dan een enkel object bestaande uit een char-array. Dat is 1 enkele pointer en niet een pointer per karakter. Je hebt dus aantal karakters + paar bytes overhead. En dus niet overhead x aantal karakters.

Wat precies de oorzaak is; geen idee, ik ben niet erg bekend met Android, maar ergens is er waarschijnlijk, inderdaad, een buffer niet helemaal bestand tegen een dergelijk "grote" input en zal 't OS (of "OOM killer" of whatever) de taak afschieten/crashen.

[Reactie gewijzigd door RobIII op 15 september 2015 23:42]

11*10 tekens geeft bij mij slechts 110 tekens, heel wat anders dan de 20480 waar jij op uit komt. Ik ben dan ook benieuwd hoe je aan de berekening komt, aan de hand van het artikel.

De onderzoeker kopieert steeds het resultaat wat hij heeft geplakt en plakt het vervolgens er weer bij, waardoor je dus steeds een verdubbeling krijgt.

Voorbeeld:
Stap 1: Typ 123
Stap 2: Kopieer 123
Stap 3: Plak 123 achter 123.
Uitkomst: 123123
Stap 4: Kopieer 123123
Stap 5: Plak 123123 achter 123123
Uitkomst: 123123123123
Enzovoort...

[Reactie gewijzigd door Xieoxer op 15 september 2015 23:24]

Precieser:

Type: ********** (10 tekens, boeie welke)

• Select all
• Copy
• Paste
• Paste

Nieuwe lengte: 20
Herhaal dat en je lengtes worden: 10, 20, 40, 80, 160, 320, 640, 1280, 2560, 5120, 10240, ...

[edit]
Was @Jaahp bedoeld... heb mijn dag niet vandaag

[Reactie gewijzigd door RobIII op 15 september 2015 23:47]

Eerst heb je 10 tekens, dan kopieer en plak je dat, dan heb je 20 tekens, dan kopieer en plak je dat, dan heb je 40 tekens....

Inderdaad, de lockscreen lijkt dus te crashen waardoor je zonder enige moeite toegang kan krijgen tot de telefoon. Dit soort bugs wil je liever niet op je telefoon hebben staan, maar Google en de fabrikanten bepalen uiteindelijk of ze een fix gaan uitrollen/maken. Ik denk dat het een lastig verhaal wordt, omdat de vorige bug (Stagefright) nog lang niet is uitgerold bij alle telefoons ondanks alle belofte van beide partijen. Mijn gevoel zegt me dat gebruikers met een Android 5.0 lang kunnen wachten voordat ze de fix kunnen ontvangen.

Andere launcher gebruiken

Hoe voorkomt dat het crashen van SystemUI via het default lock screen? Een andere launcher geeft niet per definitie een ander lock screen. Nova Launcher bijvoorbeeld heeft geen lock screen, net zoals vele anderen. GoLauncher heeft als totaalpakket wel een lock screen, maar moet je apart installeren en instellen (je kan 'm ook los gebruiken). Met daarbij geen garantie dat daar geen security bugs in zitten.

Een garantie dat er geen security bugs in bepaalde software zitten kan niemand geven. Dat geldt voor alle software!

Psies, leek me logisch... Uiteraard een andere launcher met andere lockscreen... Beveiligingssysteem lekken zijn nooit uit te sluiten natuurlijk, het is alleen de vraag of, en wanneer ze ontdekt worden.
Maar voor nu werkt het kiezen van een andere launcher prima denk ik, inderdaad samen met lockscreen.

Inderdaad, de lockscreen lijkt dus te crashen waardoor je zonder enige moeite toegang kan krijgen tot de telefoon. Dit soort bugs wil je liever niet op je telefoon hebben staan, maar Google en de fabrikanten bepalen uiteindelijk of ze een fix gaan uitrollen/maken. Ik denk dat het een lastig verhaal wordt, omdat de vorige bug (Stagefright) nog lang niet is uitgerold bij alle telefoons ondanks alle belofte van beide partijen. Mijn gevoel zegt me dat gebruikers met een Android 5.0 lang kunnen wachten voordat ze de fix kunnen ontvangen.

Voor heel veel telefoons bestaat deze hack simpelweg niet en hoeft het dus ook niet gefixt te worden. Ook kun je jezelf eenvoudig beschermen door unlock-patroon te gebruiken in plaats van de pincode.

[Reactie gewijzigd door bilgy_no1 op 16 september 2015 12:44]

Is het sowieso niet makkelijk om in iemand zn telefoon te komen door gewoon recovery te openen, whipe data / factory reset.. Dan heb je de data niet meer maar ben je wel in de telefoon?

Het idee can encryptie is juist dat kwaadwillenden niet bij de data kunnen (overheidsfunctionarissen of andersom juist justitie) zonder wachtwoord. Dat is hier dus niet meer zo. Behoorlijk gevaarlijk denk ik zo.

Evil, werkt in principe bij elke PC maar dat terzijde.
Ik hoop dat google dit snel fixt en deze snel downstream worden geïmplementeerd door de oem's.

Gelukkig ben ik hier niet kwetsbaar voor, sinds mijn lockscreentype op 'vegen' staat

Dit zijn zo van die dingen die ik Google zeker niet kwalijk kan nemen, want kom op nou, welke developer gaat even testen of dit gebeurt? Wat ik ze wel kwalijk kan nemen is dat óók dit waarschijnlijk nooit gefixt zal worden op vele telefoons. "ja maar de fabrikant..." nee, er is geen fatsoenlijk updatesysteem voor dit OS en de beveiligingsgaten, hoe klein of hoe raar dan ook, blijven zich dus wel opstapelen.

Tijd voor actie google, de tijd dringt wat mij betreft.

Edit: (off topic) Nu we het over Android lekken hebben. Mijn LG G3 had vanmorgen een update om het Stagefright lek te dichten. De Stagefright detector app geeft aan dat ik niet kwetsbaar ben.

[Reactie gewijzigd door xFeverr op 15 september 2015 22:56]

welke developer gaat even testen of dit gebeurt?

Denkfoutje: developers moeten dit niet testen. Testers moeten dit testen.
Je eigen code testen is een doemscenario.

Klopt, dit moet inderdaad door testers gedaan worden, en een groot deel ook nog een keer automatisch.

Maar dat developers hun eigen code niet mogen testen ben ik het niet mee eens. Sowieso vind ik dat je als developer met een testteam achter je toch op zijn minst aan freehand vesting mag doen. En je moet altijd werkende code opleveren aan je team die getest is door jezelf.

Juist, maar code die enkel door de ontwikkelaar getest is ook als daadwerkelijk "getest" beschouwen is niet verstandig.

Ligt aan het type test. Bij Java zul je wel zelf unittests moeten schrijven.

het probleem met android is dat fabrikanten zelf een schil erover heen kan gooien en het os niet los van de schil geüpdatet kan worden

dat is nu juist een voordeel, omdat die telefoons meestal niet het standaard lockscreen gebruiken.

De software kwaliteit van de fabrikanten is hoogst waarschijnlijk slechter dan die van Google. Dus misschien zit deze fout daar dan niet in maar vast wel een andere. Die minder snel gevonden en opgelost zal worden aangezien fabrikanten daar veel minder resources voor hebben dan Google.

in dit geval waarschijnlijk wel ja, maar zodra het probleem niet met de interface te maken heeft, krijgen een hoop mensen geen fix voor de problemen. Als de onderdelen los getrokken worden, kun ze los geüpdatet worden. Hierdoor zullen een hoop security bugs sneller geüpdatet worden

Dit zijn zo van die dingen die ik Google zeker niet kwalijk kan nemen, want kom op nou, welke developer gaat even testen of dit gebeurt?

Eentje met miljoenen, zo niet miljarden gebruikers die vertrouwen hebben in het systeem dat ze kopen? Het lockscreen - en erger nog, de encryptie - moet niet te omzeilen zijn door een crash.

Ik snap wel dat het lockscreen niet te omzeilen mag zijn, maar ik snap ook dat software fouten kan bevatten. Als ze dit snel oplossen en iedereen krijgt de fix is het allemaal goed. Maar dát is juist het grote probleem, niet deze fout in het lockscreen (die is immers al gefixt) maar het updatebeleid.

Ik mag toch aannemen dat google juist dit soort dingen gaat testen. Okee het lockscreen weg hebben is tot daar aan toe, maar ook daadwerkelijk de encryptie uitschakelen? Ik zie niet hoe dit normaal is.
Android is een java achtig iets. Daar heb je exceptions genoeg om dit af te vangen op een manier waardoor dit niet voorkomt. Een bufferoverflow is echt de meest basale vorm van "hacking" die al tientallen jaren wordt gebruikt. Beetje jammer dit.

Google moet hier wat aan gaan doen binnen korte tijd. Het gehele update systeem eens op de schoo gooien. Een GUI hoort een lage koppeling te hebben zodat je afzonderlijk updates kan uitvoeren. Dat is kennelijk niet gebeurd.

Dit heeft niet zoveel met het uitschakelen van encryptie te maken, echt puur alleen het lockscreen. Deze telefoon is al decrypted, want dit gebeurt tijdens het bootproces. Hoe kan het systeem uberhaupt de encryptie omzeilen als het de sleutel nog niet heeft gekregen van de gebruiker.

Als deze telefoon dus uitvalt/opnieuw opstart, en encryptie is ingeschakeld, zal dit dus niet werken. Het Android OS kan namelijk niet laden zonder de sleutel.

Dan is die "encryptie" dus kompleet nutteloos. Het heeft nul zin om je boot bestanden encrypted op te slaan, want die zijn open source van internet te trekken.

Het gaat juist om de bestanden van de gebruiker die je met het wachtwoord/patroon beveiligd. wat jij omschrijft is gewoon stom en ik hoop niet dat het ook echt klopt, want dan ben ik heel blij dat ik geen android heb. Als ze soiets bassaals al verkeerd doen dan houd het voor mij belemaal op.

de gehele telefoon is encrypted inclusief de bestanden van de gebruiker, de apps en het Android systeem. Een klein deel van het systeem niet, want dat is nodig om het apparaat op te starten en om de decryptiesleutel te geven.

Ik weet niet of je BitLocker kent en gebruikt in Windows? Same story. Dus, mocht het apparaat uitvallen heb je toch echt de sleutel (het wachtwoord) nodig.

[Reactie gewijzigd door xFeverr op 16 september 2015 09:52]

Er staat duidelijk vermeld in het artikel dat de gehele encryptie van het toestel omzeilt wordt met deze hack. Daar is dus niet per se een wachtwoord sleutel voor nodig kennelijk. De decryptiesleutel is je password iedere keer als jij je toestel vergrendeld hoort de boel dus op slot te gaan voor alles wat nog geen toegang had toen het hek dichtging.

Maar kennelijk is het password niet direct de sleutel, maar is het afwezig zijn van het lockscreen voldoende om alles weer open te gooien. Een simpele crash zou dit soort dingen nooit mogen veroorzaken.

Het volgende staat vermeld in het artikel:

Het maakt voor de bypass niet uit of encryptie aan staat of niet.

En zoals ik zei, het maakt inderdaad niet uit of encryptie aan staat of niet, want het toestel is al opgestart en de encryptiesleutel is al opgegeven.

Precies en dat is toch belachelijk? Zelfs al heb je de boel encrypted dan wordt dit ongedaan gemaakt zodra je toestel aanzet en de eerste keer je wachtwoord invoert?

Mijn iPhone heeft "alles" (dat is wel de implementatie, maar daar is een en ander aan op te merken) standaard encrypt en het maakt niet uit wat ik doe maar ik moet per se een wachtwoord invoeren of unlocken met fingerprintID. Alle gegevens zijn ontoegankelijk voor derden. Zelfs voor iTunes op mn eigen mac.

Ik vraag me altijd af hoe je dit soort kwetsbaarheden ontdekt?

Edit: ander voorbeeld wat ook een manier is om een kwetsbaarheid te vinden.
http://www.wired.com/2015...ses-android-lock-screens/

Gordon says he stumbled on the lock screen vulnerability while messing with his phone during a long East Texas road trip. “I’m sitting in the passenger seat, bored, with no signal on my phone, so I start poking around and seeing what unexpected behavior I can cause,” he says. “A few idle hours of tapping every conceivable combination of elements on the screen can do wonders for finding bugs.”

[Reactie gewijzigd door R_026 op 15 september 2015 22:54]

ik vraah me eerlijk gezegd af of deze lek wel echt relevant is.. je hebt namelijk de telefoon nodig (meestal vrienden/familie) en ik denk niet dat die zoiets zouden doen..
maar toch, fijn dat iemand hier op mysterieuze wijze achter komt, hoe veiliger hoe beter

Soms worden ze ook wel eens gestolen...

in het geval je telefoon gestolen wordt zal je lockscreen niet veel helpen.. een beetje ervaren telefoondief laat zich daar iig niet door tegenhouden
maar goed, snap wat je bedoelt, lockscreen is altijd veiliger

Dat je de encryptie ermee kan omzeilen is wel kwalijk. De FBI heeft er nog eens Google voor moeten contacteren.

Dit lek is zeker wel relevant, als je toestel gestolen wordt of als je hem verliest, en iemand anders pakt je toestel.

Hoop ook echt dat de recovery menu in de toekomst beveligd kan worden, zodat als men zijn toestel is verloren, hiermee het toestel niet meer kan resetten, zodat hij hem zelf kan gebruiken.

Doet me denken aan een lek in windows 95, waar je het wachtwoord kon omzeilen door de printerinstellingen te bereiken.

Niet best zo'n lek, maar, wat is de kans dat je hier slachtoffer van wordt. Fysiek toegang tot je telefoon, en een wachtwoord is er nodig. Goed dat het gevonden wordt, hoop dat google ze er een paar centen voor geeft, en snel patchen. Aan je woord houden, dat er iedere maand beveiligingsupdates komen!

In Windows 95 kon je het wachtwoord omzeilen door op "Cancel" te drukken

Nu je het zegt, windows 98, was het dan waar je via de printerinstellingen het wachtwoord kon omzeilen. Waarom je bij de printerinstellingen kon als je in moest loggen, is me echt een raadsel.

Het is toch bijzonder om te zien hoe complex de handelingen zijn om dergelijke bug uit te voeren. Is toch bijzonder op op zoeits te komen. Alhoewel deze bug logischer lijkt dan de bugs die het lockscreen van de iPhone een tijd geleden had.

Zo bijzonder vind ik dit niet.
- apps kunnen crashen en een crash kan impact hebben op security
- een buffer overflow kan dat veroorzaken.
- te veel input kan hier een oorzaak van zijn
Dat je een aantal handelingen moet uitvoeren om van scherm a naar scherm b te gaan voor text copy paste, ja daar moet je even goed voor zitten, maar is makkelijk te achterhalen.

Dus eigenlijk vind ik dit slordig van het team om niet over na te denken bij het ontwikkelen en het testen. Zeker voor een app die je toegang geeft voor de telefoon. En zeker bij een groot bedrijf zoals Google.

Ik krijg het op mijn S6 met fingerprint/wachtwoord unlock niet aan de praat.
Mede omdat alle copy paste acties geblokkeerd zijn voor unlock.

Handmatig unlock met zelf te typen, kun je niet snel genoeg .. sleep kicked automatisch in, ook al ben je aan het typen.

dat komt omdat het geen aosp lockscreen is.

het is echter niet onmogelijk dat het ook in anderr lockscreens zit, omdat theoretisch elke app op deze manier kan crashen.

Gevaarlijke zaak! Toch mooi dat onderzoekers dit soort dingen onderzoeken en publiceren, zo kan het lek tenminste worden gedicht. Het wordt uiteindelijk toch gevonden, misschien zelfs door iemand met kwade bedoelingen. Gelukkig gaan bedrijven maandelijkse beveiligingsupdates uitgeven.