Stagefright-sårbarhetene i Android har vært en vekker for mange i økosystemet, noe som har ført til mer oppmerksomhet rundt sikkerheten til selve Android-programvaren. (Bilde: www.norebbo.com)

ASLR

Google-ansatte utfordrer Android-sikkerheten

Viktig sikkerhetsfunksjon fungerer langt dårligere enn det selskapet har gitt uttrykk for.

Sikkerheten til Android-operativsystemet har kommet mer i søkelyset i år enn tidligere på grunn av sårbarheter, inkludert sårbarhetene som har blitt funnet i Stagefright-biblioteket. Nå peker sikkerhetseksperter hos Google på at mottiltakene, som selskapets PR-avdeling har snakket så varmt om, kan være utilstrekkelige.

Bakgrunn: Det haster å fjerne Android-sårbarheter 

Randomisering

Felles for de fleste av Android-sårbarhetene som har blitt kjent i det siste, er at de tilsynelatende kun har latt seg utnytte i visse utgaver av Android. Dette skyldes flere faktorer, men Google har spesielt nevnt teknikken ASLR (Address Space Layout Randomization), som kort fortalt dreier seg om å gjøre det vanskelig for angripere å gjette hvor i minnet prosesser og funksjoner er plassert, ved å gjøre denne plasseringen vilkårlig.

Project Zero er en egen avdeling hos Google som leter etter sikkerhetshull, både i Googles egen og andres programvare. I forrige uke kom teammedlemmet Mark Brand med et blogginnlegg som beskriver hvordan en av Stagefright-sårbarhetene kan utnyttes i nyere Android-versjoner, altså versjon 5.0 og nyere.

Enheten som ble benyttet, er en Nexus 5-mobil. Sårbarheten som omtales ble fjernet fra denne enheten gjennom en oppdatering som ble rullet ut før Project Zero publiserte blogginnlegget.

Blogginnlegget ble først omtalt av Ars Technica.

Les også: Må sende ut ny sikkerhetsfiks til Android 

«Rå makt»

I blogginnlegget beskriver Brand hvordan man greide å omgå ASLR-funksjonen i Android. Det ble rett og slett gjort ved hjelp av «rå makt», altså ved hjelp av prøve- og feile-metoden, og likevel med en relativt høy suksessrate.

Årsaken til dette er at entropien til ASLR i 32-bits Android har en entropi på bare 8 bit. Dette betyr at det bare finnes 256 mulige basisadresser i minnet for det biblioteket man er ute etter.

– Jeg visste av ASLR på 32-bits var en smule utrygt, men jeg trodde ikke det var så dårlig, skriver Brand.

Installert av minst 100 000: Tilsynelatende legitim Android-app utnytter kjent sårbarhet 

Medieserver-krasj

Utnyttelse av den aktuelle sårbarheten, som skyldtes en overflytsfeil i libstagefright.so, får medieserveren i Android til å krasje. Det skjer ingen skade utover dette dette, så lenge ikke det riktige minneområdet blir lokalisert.

En faktor som i stor grad bidrar til å gjøre denne tilnærmingen mulig, er et medieserveren automatisk startes opp på nytt dersom den har krasjet. Dermed får angriperen nye muligheter til å gjøre et angrepsforsøk, men i hvert tilfelle med en ny, vilkårlig basisadresse. I tillegg hindrer Android at medieserver-prosessen kan startes oftere enn hvert femte sekund.

Det betyr at man kan gjøre et angrepsforsøk tolv ganger i minuttet, med 1/256 sannsynlighet for å lykkes. For hvert minutt som angrepet varer, er sannsynligheten for å lykkes på omtrent fire prosent, skriver Brand.

Certifigate: Hullet kunne la hackere høre på samtaler og titte ut mobilkameraet 

Vannhullangrep

Han legger til det nok kunne vært mer elegant og pålitelig å bruke mer sofistikerte metoder, men at det ikke er usannsynlig at man i forbindelse med et såkalt vannhullangrep kan få brukeren til å oppholde seg lenge nok på en ondsinnet webside, til at angrepet lykkes. Ikke minst gjelder dette via annonser som vises inne i apper ved hjelp av å bruke WebView-komponenten i Android.

Som resultat av arbeidet som det har gjort for å utvikle angrepskoden, har Project Zero delt flere forslag med teamet som har ansvaret for Android-sikkerheten. Dette handler først og fremst om forsterkning av implementeringene av komponentene libc og mmap.

Les også: Gjør Android-appene klare for «Marshmallow» 

Til toppen