Google voorziet Android-kernel van aanvullende bescherming

De ontwikkelaars van Android hebben een aantal aanvullende maatregelen genomen om de Linux-kernel van het besturingssysteem beter te beschermen. Dit doen zij onder andere door toegang tot de kernel te beperken.

Ontwikkelaar Jeffrey Vander Stoep legt uit dat Android voor het handhaven van het beveiligingsbeleid afhankelijk is van de Linux-kernel. Deze zorgt bijvoorbeeld voor de bescherming van het geheugen van processen in userspace, die uit veiligheidsoverwegingen gescheiden is van kernelspace. Een van de genomen maatregelen is het beperken van de toegang door de kernel tot geheugen in de userspace. Dit maakt aanvallen moeilijker, omdat kwaadwillenden op die manier minder controle kunnen uitoefenen over kernelgeheugen.

Ook is er meer beveiliging tegen stack buffer overflows aangebracht. Daarnaast hebben de ontwikkelaars toegang tot de kernel beperkt en daarmee het aanvalsoppervlak verkleind. Dit deden zij bijvoorbeeld door in Android Nougat de prestatietool 'perf' voor gebruikers uit te schakelen. Voor ontwikkelaars blijft deze echter nog bereikbaar. Door bepaalde code te verwijderen of toegang tot ingangspunten te beperken zijn er minder mogelijkheden om een systeem aan te vallen.

Zo zouden veel kernelkwetsbaarheden in Android voortkomen uit drivers en via de ioctl-systemcall te bereiken zijn. Via een systemcall kunnen userland-applicaties verzoeken aan de kernel sturen. Via een whitelist willen de ontwikkelaars deze calls tot alleen de essentiële delen beperken voor apps van derde partijen.

Reacties (53)

[BoomSmurf]

Staat niet in het artikel maar de runtime linker implementeert nu ook handle randomization. Je kunt het resultaat van dlopen() nu dus niet zomaar meer gebruiken om symbols te routen (aka detour) in de PLT/GOT.

Hiermee kon je in principe elke call vanuit een process onder jouw controle naar een shared library hijacken. Een normale app kan daar niet heel boeiende/praktische dingen mee (alhoewel er wel een paar leuke trucs mee te doen zijn), maar als een kwaadwillende app er in de een of andere manier in slaagt om een andere app zover te krijgen zijn code te laden, dan kunnen daar interessante dingen mee gedaan worden. Let wel, dit is dus voornamelijk iets wat gebruikt wordt *na* de initiele privilege escalation exploit, wat code injection doorgaans makkelijk mogelijk maakt door een debugger na te apen.

Om een leuk praktisch voorbeeld te noemen, toen Pokemon Go net uitkwam (en voor die Rus het hele protocol online gooide), heb ik deze techniek gebruikt om alle communicatie af te luisteren nog voor deze geencrypt werd, door de SSL_read en SSL_write functies van OpenSSL te routen. (Had natuurlijk eerst een HTTPS proxy moeten proberen, maar ja, wat voor bende oelewappers gebruikt anno 2016 nog geen certificate pinning? Ik spreek er schande van)

Naast afluisteren kun je natuurlijk ook wijzigen. Stel je voor dat je malware op je telefoon hebt die deze techniek toepast op je internetbankieren app. In een ideale wereld zou die app zo in elkaar zitten dat zelfs met zo'n niveau van toegang geen misbruik gemaakt kan worden, maar we weten allemaal dat de realiteit anders is. Voorbeelden genoeg te bedenken waar dit potentieel problematisch is.

Zover ik weet is deze wijziging nergens gedocumenteerd, maar hij is wel geimplementeerd (zie NP5 sources in AOSP).

Helaas pindakaas heb ik ondertussen al een workaround gevonden die de hele handel (pun intended) omzeilt

[Reactie gewijzigd door BoomSmurf op 8 augustus 2024 19:43]

[teddysleep]

Elke verdere ontwikkeling op vlak van beveiliging zie ik graag komen. Helaas is een systeem maar zo veilig als de zwakste schakel. Dan mag je systeem nog zo veilig zijn, als je gebruiker niet weet hoe hij het (veilig) moet gebruiken, heeft het allemaal geen zin.

[infernal_nl]

Ik ben het niet eens met je stelling, een systeem is inderdaad zo sterk als de zwakste schakel, maar ik zie de eindgebruiker niet als de zwakste schakel, die kan inderdaad bijvoorbeeld allerlei malware e.d. binnen slepen, goede code zorgt er dan voor dat malware e.d. niet bij de kernel of andere componenten kunnen komen, de zwakste schakel hoeft dus niet bij de eindgebruiker te liggen.

[Verwijderd]

Interessant! Leg eens uit hoe "goede code" voorkomt dat de gebruiker sudo'd waar dat helemaal niet zou hoeven? De slimste malware is die de gebruiker zélf laat zorgen voor elevation of privilege. Geen kernel die daartegen bestand is...

[GekkePrutser]

Sudo (en preciezer gezegd het gebruik van een almachtige root user) is al een deel van het probleem.

Je gebruikt sudo om een bepaald iets te kunnen doen. Bijvoorbeeld een systeemfile aanpassen of een poort onder de 1024 openen. Maar je kan dit normaal gezien alleen doen door *alle* root rechten al dan niet tijdelijk af te geven.

Je hebt tegenwoordig frameworks zoals SELinux, grsecurity en AppArmor die dit in veel kleinere hapjes kunnen doen. Dan kan je een bepaald programma alleen het recht toewijzen om 1 bepaalde systeem file te veranderen. Of alleen poort 80 openen en verder helemaal niks.

Maar ondanks het bestaan van 3 uitgebreide security mechanismen voor Linux, wordt er door de mainstream distro's nog steeds niet standaard gebruik van gemaakt. Dat vind ik wel jammer. Nu moet je voor elke app uitzoeken welke rechten het nodig heeft en dat is een hoop gedoe, dit zou ook met de package meegeleverd kunnen worden zodat het gewoon out of the box werkt (en een stuk veiliger is bovendien).

Edit: En zoals hieronder genoemd wordt bestaan er ook nog systemen om applicaties in een sandbox/container te draaien zoals LXC. Maar ik zou graag een combinatie van beiden zien, anders is het overkoepelende systeem nog steeds helemaal open als er hoe dan ook root toegang verkregen wordt.

[Reactie gewijzigd door GekkePrutser op 8 augustus 2024 19:43]

[Verwijderd]

Precies waarom ik sudo als voorbeeld neem Voor al dat soort systemen, ook AppArmor cs geldt dat de grootste uitdaging voor malware is om de zwakste schakel ervan te overtuigen dat het echt héél héél nodig is dat een zaklampapp de microfoon kan gebruiken en toegang heeft tot de contactenlijst, of ervan uit te gaan dat het gros van de zwakste schakels überhaupt niet kijkt waar ze toestemming voor geven.

[Verwijderd]

En zoals hieronder genoemd wordt bestaan er ook nog systemen om applicaties in een sandbox/container te draaien zoals LXC. Maar ik zou graag een combinatie van beiden zien, anders is het overkoepelende systeem nog steeds helemaal open als er hoe dan ook root toegang verkregen wordt

Je moet die dingen op iets langere termijn zien als dat jouw huidige Android telefoon zal mee gaan. Maar uiteraard is LXC bedoeld om met SELinux samen te werken, ja.

Trouwens: momenteel gaat het erg snel allemaal. Zou me niets verbazen moesten er nog lang voor uw huidige Android de geest geeft al toestellen komen die letterlijk belachelijk veel beter zijn dan je huidige toestel. Op alle vlakken. Je kids gaan je nog uitlachen. Wacht maar af.

[rvt1]

Sudo heeft weinig te maken met de almachtige root user.

Je kunt ook sudo configureren voor een gebruiker om iet's specifieks te mogen doen. Je hoeft dus niet root te worden. Wat je helaas wel vaak ziet is dat systemen met sudo zo wordt geconfigureerd dat je dus wel root rechten krijgt, raspberry pi is zo'n mooie voorbeeldje.

Mocht je dit zelf al weten, prima... Voor de mensen die Linux niet zo goed kennen dus wel een leer momentje.

[infernal_nl]

Door zelf de gebruiker zelf geen toegang te geven tot de kernel, maar alleen 'system'? Het op die manier loshalen van elkaar, waarbij system een afweging kan maken of de action die user aanvraagt wel klopt/toe laat in de context waarin het de actie vraagt.. is maar een hersenspinsel hoor..

[Verwijderd]

Als "goede code" de gebruiker tegen zichzelf in bescherming neemt is dat slechts een bevestiging dat de gebruiker inderdaad de zwakste schakel is. Dat is geen "goede code". Een deur die je niet kunt vergeten op slot te doen omdat hij niet van het slot kan is geen "goede deur".

[Ed Vertijsment]

In bijvoorbeeld OS X is veel toegang zelfs voor root niet mogelijk, ook niet met chmod/chown. Zelfs met sudo zou de beveiliging dan in stand blijven.

Echter is gebruiker idd nog steeds de zwakste schakel, vergeet niet dat de gevoeligste informatie vaak in userspace staat.

[valvy]

Tenzij de gebruiker system integrity protection uitschakeld

En ik ken genoeg apps die niet werken naast rootless

[Terracotta]

Op welke Smartphones hebben 'gewone gebruikers' sudo rechten?

[Ed Vertijsment]

Geroote phones?

[Terracotta]

Sinds wanneer valt rooten onder 'gewoon gebruik'.

[Zunflappie]

Het grote gedeelte van niet-grote-merken-Android-telefoons is standaard geroot.
Dat wil zeggen: er zit geen beperkingen op je eigen telefoon door de fabrikant.

Op mijn Jiayu, Wiko en ZTE had ik, fabrieksaf, direct een geroote telefoon. En dat is prima, zo is het installeren van een andere ROM een eitje.

[David Mulder]

Ehm? Wat? Mocht dat waar zijn, dan zijn dat extreem onveilige telefoons. Waarom? Omdat extreem veel gebruikers niet begrijjpen wat het betekend om een applicatie root toegang te geven. Het is niet zonder reden dat Cyanogenmod (waar de optie standaard in zit) hem nog steeds verstopt in het developer menu wat moet worden geactiveerd via een 10x tap op een ongerelateerd menu item.

Daarnaast is root toegang totaal niet noodzakelijk om een ROM er op te zetten, dus sowieso vermoed ik dat je dingen door elkaar haalt. Mogelijk dat die telefoons standaard met een geunlockte bootloader worden geleverd.

[Terracotta]

unlocked bootloader != root.

[doom71]

Het hebben van een unlocked bootloader is niet hetzelfde als root access op je telefoon. Om root access te hebben zul je eerst nog een app als supersu moeten installeren.

[mxcreep]

Vergeet niet 'onze' groep gebruikers, veel flashen custom roms, installeren su tooltjes etc. Als je daar je kwaadwillende spullen in stopt op een slimme manier heeft geen mens dat door ook al is de code misschien opensource. Bijna niemand compiled zijn eigen binaries. Tevens staan op die telefoons vaak allerlei developer opties aan. En het is ook nog een groep die vaak centjes te besteden heeft en waar wat te halen valt...

Hmm shit... ik kom er net achter dat ik dus ook een target ben

[lever]

Je zag het al met Pokemon go. Mensen gingen massaal de game via internet binnen halen. Als de game dan van allerlei rechten vraagt drukt iedereen gewoon op ok.

De eindgebruiker is in mijn ogen inderdaad de zwakste schakel.

[Verwijderd]

Eigenlijk wil je gewoon naar een model gaan waar iedere app in een lightweight container draait. Als een app dat malicious is en/of wordt doordat er op ingebroken is, dan kan de process enkel maar aan de inhoud van die container en/of de rechten van die container aan.

Maak je het filesystem van die container een copy on write (zoals btrfs ondersteunt), dan rol je ook nog na het afsluiten van de app alle changes terug.

Indien een app toegang nodig heeft tot bv. de foto's of de muziek, dan geeft de gebruiker read-only en directory per directory de rechten aan de container. Maar niets meer en niets anders. Malware die files gaat encrypteren kan dan enkel het FS van de container encrypten. Maarja. Die changes rollen we toch terug wanneer de app afsluit.

Nada. Gedaan met die malware.

Komt er trouwens aan. Dit is hevig in ontwikkeling in de Linux wereld.

[Soldaatje]

Android apps draaien toch al sinds het allereerste begin in een sandbox?

[Rafe]

De sandbox betekent dat elke applicatie onder een eigen user account draait met beperkte rechten. Zoals freaxje al omschrijft gaan systemen als LXC nog een stuk verder: "complete isolation of an applications' view of the operating environment, including process trees, networking, user IDs and mounted file systems."

[Verwijderd]

Een eigen useraccount en bv. chroot gebruiken zou natuurlijk al redelijk goed zijn. Maar die processen kunnen nog altijd aan alle hardware waar die user aan mag komen van de kernel. Dat kunnen we met LXC per container beter gaan organizeren. Nochtans is zo'n container eigenlijk maar even duur als chroot. Uw normale userspace draait immers ook maar gewoon in een container. Alles containers :-)

Het is vooral door de combinatie met btrfs's terugrollen van FS wijzigingen, cgroups om resource limieten op te leggen en goedkope namespace isolatie zoals je al aangaf dat het interessant wordt om individuele apps in containers te laten draaien.

Voorts het feit dat we UNIX domain sockets (zoals D-Bus bv.) gaan kunnen routen tussen containers en/of service activation van D-Bus om services die in containers moeten draaien snel op te brengen en terug neer te halen. Dat maakt dat het ook eenvoudig wordt voor applicatie developers om het te gaan gebruiken. Mja en dan komt systemd om de hoek kijken natuurlijk. Maar als ik dat woordje uitspreek dan breekt de slashdot-hel wel los voor één of andere bizarre reden. Docker, ook goed voor mij: zolang het maar één API is. Één.

Komt goed

[kidde]

Is dat niet chroot?
Ed: Net gelezen wat het verschil is, LXC is veel uitgebreider en lijkt meer op FreeBSD jails:

https://wiki.gentoo.org/w..._virtualization_.28LXC.29

[Reactie gewijzigd door kidde op 8 augustus 2024 19:43]

[Verwijderd]

Dat zou je kunnen zien als een voorganger van LXC. LXC gaat wel nog een heel eind verder.

[kdekker]

Komt wel met een berg extra administratief werk. Je wilt dingen als taal en andere regionale settings maar 1x opslaan. En je wilt niet weten waar de Linux kernel allemaal kijkt. Idem filesysteem toegang. Het moeilijke van beveiliging is een goed evenwicht zien te vinden tussen gebruiksgemak en veiligheid. Die consensus kan best verschuiven door de tijd heen, maar domweg alles 100% dichtspijkeren is echt geen oplossing.

Een copy-on-write is leuk, maar niet als je dat iedere keer moet doen. En ik vraag me af of BRTFS en Android al samengaan (Linux en BRTFS is er wel, maar dan wel op een apparaat met genoeg geheugen en rekenkracht). Niet ieder FS is dan te kiezen.

[Verwijderd]

Mja wat Android doet is natuurlijk irrelevant op langere termijn. Is niet echt waar, maar toch.

Als google btrfs niet op Android zet zal dat toch geen enkele opensource Linux developer tegenhouden om met die btrfs iets te maken dat triljarden keer beter is dan om het even wat Google's Android zweetkot mee af komt. Zal ook gebeuren ook. Zie NT kernel vs. Linux kernel voor hoe de geschiedenis is verlopen. De echte goei kernel-devs geven er geen f. om wat de grote bedrijven doen of proberen op te leggen met hun monopolies. Dan gebruikt over een paar jaar iedereen wel btrfs. En alleen Android niet. Dikke pech voor Android dan (moest het zo geschieden).

Die regionale settings kunnen we bv. wel met dconf oplossen. Die dconf gebruikt mmap van een gvariant gebazeerde data structuur en D-Bus. Dan kan tussen containers geshared worden moest dat nodig zijn.

[kdekker]

Een filesysteem wordt niet even gemaakt. Ik denk dat je een aantal zaken onderschat. Alleen al dat er diverse file systemen zijn, en - ik praat even voor de desktop en server - de grote Linux distro's verschillende keuzes maken voor een default filesysteem, laat al zien dat het niet even triviaal is.

Als je een smartphone hebt met 200GB file systeem, dan ben je (in 2016) een gesjeesde kerel of dame. Bijna niemand heeft dat soort groottes. Echt goeie devs hebben brood op de plank nodig en zullen echt niet even een ander/nieuw file systeem inbakken als daar geen dringende behoefte toe is.

Datzelfde geldt voor alternatieven voor Android. Ze zijn er bijna niet. Je kunt wel mopperen op Google, maar daarmee verander je de wereld niet. Ik ben zelf zeer beperkt bekend met Android, maar ik zie geen echte voor of nadelen t.o.v. de andere spelers op de smartphone markt. Grosso modo is het toch veel van hetzelfde.

(een smartphone is voor mij niet echt iets waar ik veel tijd mee verstook, dat bepaald wellicht voor een deel mijn reactie).

[Verwijderd]

Ja euh. Mijn Jolla zijn /home is gemount met btrfs. Out of the box. De / trouwens ook. De /var/systemlog is ext4. Klinkt inderdaad overkill om de logs op een btrfs te zetten.

Heb wat contract werk voor Jolla gedaan. Ik weet dat het niet veel tijd kostte om dat gewoon op btrfs te zetten.

De voordelen van btrfs zijn er natuurlijk wel. Maar ik denk wel dat ook Android ooit gewoon naar btrfs zal gaan. Van zodra er applicaties zijn die gebruik willen maken van dat FS haar features.

Voorlopig is het probleem gewoon dat de consument die zever die Android is toch goed genoeg vindt. Dus waarom zou Google innoveren? Precies. Niet.

[Finwe]

btrfs is helemaal niet zo geschikt voor Android, omdat Android devices veelal op flash draaien. Dan zijn ext4/f2fs veel betere keuzes voor performance, hoewel je dan natuurlijk wel wat btrfs features mist.

[moozzuzz]

En wat dan met een app die foto's maakt? Nooit meer opslaan van foto's ?

[Verwijderd]

Dan laat het hoofd-OS de gebruiker een schermpje zien: de applicatie "Mooie vakantiefoto's schieten" wenst te schrijven op de plaats waar "foto's" staan, wilt U dit toelaten? Terwijl die vraag gesteld wordt leg je de container in pause. Dat kan zo met Docker en zo rechtstreeks met cgroups. Dit is m.a.w. standaard container functionaliteit.

Wanneer de gebruiker ja antwoord dan unfreeze je de container nadat de container de nieuwe schrijfrechten heeft gekregen. Even later zal "Mooie vakantiefoto's schieten" kunnen schrijven in die folder.

Zo dramatisch doen als "nooit meer opslaan van foto's?" hoeft helemaal niet. Vanzelfsprekend kan zoiets uitgewerkt worden.

[moozzuzz]

Succes met je OS/app - je kan theoretisch gelijk hebben maar zo'n foto-app zal de gebruiker zot maken. Wie wil nu elke keer moeten J/N klikken om een foto op te slaan? (Windows UAC anyone) en hoe effectief gaat dát zijn...

[mxcreep]

COW filesystemen zijn niet heel erg gunstig voor de levensduur van flash geheugen volgens mij...

[Verwijderd]

De levensduur van je telefoon is ver, héél héél erg ver, onder de levensduur van de flash disk die er in zit. Ik geloof een factor tien: die flash disk zal letterlijk tien keer langer mee gaan dan je telefoon zelf. En dan overdrijf ik want waarschijnlijk zal de flash disk twintig keer langer mee gaan.

[ToFast]

Oei, ben benieuwd wat dit voor consequenties heeft voor de powerusers. Ik draait o.a. een custom rom, xposed framework en custom kernel (overclock CPU en GPU, undervolt deep sleep frequentie, blink buttons, iets meer stroom naar trilmotor en ga maar zo door alleen al door de kernelaanpassingen).

[XVI]

Een custom rom zegt het al. Hij is custom, dus je kan die zaken ook weer gewoon uitschakelen. Verder denk ik dat de betere beveiliging in de praktijk maar weinig van dat soort aanpassingen in de weg zal zitten. Rooten zal wel lastiger kunnen worden, maar elke telefoon zou dan ook gewoon vanuit de fabriek volledig te unlocken moeten zijn met behoud van garantie op de hardware.

[Verwijderd]

Er bestaat altijd nog zoiets als systemless root. Wellicht dat dit hierop nog gebruikt kan worden.

[BoomSmurf]

Dit heeft alleen invloed op exploits die de initiele root verschaffen. Het heeft in ieder geval geen invloed op via TWRP of iets dergelijks SuperSU installeren.

Van deze dingen zijn alleen de SELinux-based ioctl restricties relevant voor root apps, en die worden al een tijdje gepatched door SuperSU.

seccomp zou relevant kunnen zijn, maar wordt vooralsnog alleen toegepast op Android's media processen om minder exploit gevoelig te zijn (veel recente exploits liepen via deze processen).

[goarilla]

Ik dacht dat userland al extra gescheiden was omdat apps in een JVM draaien ?
(Arbitraire) ioctl's naar brakke drivers sturen zou toch al quasi onmogelijk moeten zijn.

[BoomSmurf]

Apps kunnen ook native libraries gebruiken, en die kunnen gewoon ioctls uitvoeren.

[rudeboy75]

Mooi man, een goed voorbeeld hoe het open source principe werkt. De android ontwikkelaars verbeteren iets en door dit te delen met de beheerders van de code zorgen ze dat deze verbetering in toekomstige releases zit. Voor hun zelf, maar ook voor de rest van de wereld.

[H!GHGuY]

Niet echt.

Ze gebruiken gewoon ofwel Grsecurity (die apart ontwikkeld wordt wegens... "verschillende persoonlijkheden") of de laatste kernel waarin sommigen delen van Grsecurity aan het herimplementeren zijn, soms net iets minder krachtig om de performance niet in de weg te zitten.

Dus, nee Android neemt hier echt niet het voortouw, ze profiteren gewoon van andermans werk.

[moozzuzz]

Dus, nee Android neemt hier echt niet het voortouw, ze profiteren gewoon van andermans werk.

En daar profiteren dan weer alle Android gebruikers van, toch? De conclusie blijft maar de credits moeten idd niet aan Android gegeven worden!

[asdfCYBER]

Heeft deze ontwikkeling nog gevolgen voor het rooten van smartphones?

[mxcreep]

Uiteraard, veel exploits vinden pas plaats na initieel een elevation exploit te hebben uitgevoerd, ofwel eerst root rechten verkrijgen. Dus ook de mogelijkheden om als root dingen te exploiten worden beperkt hierdoor.

[N8w8]

Mocht je interesse hebben in deze ontwikkelingen, dan is de CopperheadOS ROM (voor Nexussen) zeker het bekijken waard!
Misschien is bovenstaande wel deels daardoor geinspireerd.
edit: nu ik mn eigen link ns bekijk (), komen inderdaad veel van zulke technieken daarvandaan.

[Reactie gewijzigd door N8w8 op 8 augustus 2024 19:43]

[rob12424]

De titel is een beetje misleidend: het doet denken dat er fouten in de kernel zitten. Terwijl het toch echt om het besturingssysteem dat op de kernel draait gaat die bepaalde afhandelingen van en naar de kernel onveilig afhandelde.

Immers de kernel moet een kleine footprint hebben en de gebruikte aperaten zijn heel divers, waarbij niet elk aperaat deze beveiliging nodig zal hebben.

[Reactie gewijzigd door rob12424 op 8 augustus 2024 19:43]

[mxcreep]

Je hebt gelijk, alleen door nu extra beveiliging op kernel nivo toe te passen wordt voorkomen dat de er bovenop draaiende laag mogelijkheden tot onveilige akties heeft. Ik vind het in elk geval een goede zet.

[joo5ty]

Beetje offtopic, maar wel mbt veiligheid android..
Tegenwoordig zie je steeds meer crypto geld op android wallets staan. Hoe veilig is dit geld? Ook al is de app goed opgezet, dan nog kunnen andere apps misschien je private blockchain key stelen?