Stagefright: The Exploit That Changed Android

En av de sterkeste sidene til Android har først og fremst vært dens åpen kildekode-natur, som gjør det mulig for interessenter å dele, modifisere og omfordele OS på en måte som passer deres spesielle behov. Men denne fordelen med å være åpen kildekode fungerer som et tveegget sverd når det kommer til problemer med skadelig programvare og sikkerhet. Det er lettere å finne og reparere feil når du har mange dyktige bidragsytere på et prosjekt hvis kildekode er fritt tilgjengelig. Å fikse problemet på kildenivå fører imidlertid ikke ofte til at problemet løses i hendene til sluttforbrukeren. Som sådan er ikke Android det fremste valget når det gjelder å velge et OS for datasensitive bedriftsbehov.

På Google I/O 2014 ga Google sitt første dytt mot et sikrere og bedriftsvennlig økosystem med lanseringen av Android For Work-programmet. Android For Work tok i bruk en tvillingprofiltilnærming for bedriftsbehov, der IT-administratorer kunne opprette en distinkte brukerprofiler for ansatte - en fokusert på arbeid, mens andre profiler overlates til de ansattes personlige bruk. Gjennom bruk av maskinvarebasert kryptering og admin-administrerte retningslinjer forble arbeids- og persondata adskilte og trygge. Deretter fikk Android For Work mer oppmerksomhet i de senere månedene, med stort fokus på sikkerheten til enheten mot skadelig programvare. Google planla også å

aktiver full enhetskryptering for alle enheter som skulle utgis med Android Lollipop ut av esken, men dette ble skrotet på grunn av ytelsesproblemer, da flyttingen ble gjort valgfri for OEM-er å implementere.

Presset for en sikker Android er ikke helt Googles arbeid, da Samsung har spilt en ganske betydelig rolle i dette via sin KNOX-bidrag til AOSP, som til slutt styrket Android For Work. Nylige sikkerhetsutnyttelser og sårbarheter i Android peker imidlertid på en oppoverbakke oppgave når det gjelder popularitet for bedriftsadopsjon. Et eksempel på dette er den nylige Stagefright-sårbarheten.

Innhold:

• Hva er Stagefright?
• Hvor alvorlig er Stagefright?
• Hva skiller Stagefright fra andre «massive sårbarheter»?
• Oppdateringsdilemmaet
• Android, Post-Stagefright
• Avslutningsnotater

Hva er Stagefright?

Enkelt sagt er Stagefright en utnyttelse som bruker kodebiblioteket for medieavspilling i Android kalt libstagefright. Libstagefright-motoren brukes til å utføre kode som mottas i form av en ondsinnet video via MMS, og krever dermed kun mobilnummeret til offeret for å utføre et vellykket angrep.

Vi tok kontakt med vår interne ekspert, XDA Senior Recognized Developer, og Developer Admin pulser_g2 for å gi en mer detaljert forklaring.

"Mens jeg skriver dette, skulle [Stagefright] utnyttelsen bli forklart på BlackHat [Link], selv om det ikke er noen lysbilder eller hvite papirdetaljer tilgjengelig ennå.

Jeg gir derfor denne forklaringen mer som en grov idé om hva som skjer, snarere enn som en dyptgående forklaring med full nøyaktighet osv.

Det er en rekke forskjellige feil som utgjør Stagefright, og disse har sin egen CVE [Vanlige sårbarheter og eksponeringer] tall for sporing:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

Dessverre er oppdateringene som er tilgjengelige ikke koblet direkte til hver CVE (som de burde være), så dette blir litt rotete å forklare.

1. [CVE-2015-1538]

I MPEG4-håndteringskoden er håndteringskoden for 3GPP-metadata (det som beskriver formatet og annen ekstra informasjon, når en video er i 3GPP-format) buggy. Den avviste ikke metadata, der dataene var for store, heller bare sjekket om de var for små. Dette betydde at det var mulig for en angriper å lage en "modifisert" eller "ødelagt" fil, som ville ha en lengre metadatadel enn den burde.

En av de store utfordringene med å skrive kode for å håndtere "ikke-pålitelige" data (dvs. fra en bruker eller fra et annet sted utenfor koden din) er å håndtere data med variabel lengde. Videoer er et perfekt eksempel på dette. Programvaren må tildele minne dynamisk, avhengig av hva som skjer.

I dette tilfellet opprettes en buffer som en peker til noe minne, men lengden på matrisen den peker på var ett element for kort. Metadataene ble deretter lest inn i denne matrisen, og det var mulig å få den siste oppføringen i denne matrisen til å ikke være "null" (eller null). Det er viktig at det siste elementet i matrisen er null, siden det er slik programvaren forteller at matrisen er ferdig. Ved å kunne gjøre den siste verdien til ikke-null (siden matrisen potensielt var ett element for lite), kunne den skadelige koden leses av en annen del av koden, og lese inn for mye data. I stedet for å stoppe ved slutten av denne verdien, kan den fortsette å lese inn i andre data den ikke skal lese.

(Ref: OmniROM Gerrit)

2. [CVE-2015-1539]

Den korteste mulige "størrelsen" på metadataene bør være 6 byte, fordi det er en UTF-16-streng. Koden tar heltallsverdistørrelsen og trekker 6 fra den. Hvis denne verdien var mindre enn 6, ville subtraksjonen "flyte under" og vikle seg rundt, og vi ville ende opp med et veldig stort tall. Tenk om du bare kan telle fra 0 til 65535, for eksempel. Hvis du tar tallet 4, og trekker fra 6, kan du ikke gå under null. Så du går tilbake til 65535 og teller derfra. Det er det som skjer her!

Hvis en lengde på under 6 ble mottatt, kan det føre til at rammer blir feil dekodet, siden byteswap-prosessen bruker variabelen len16, hvis verdi er hentet fra en beregning som begynner med (størrelse-6). Dette kan føre til at en mye større bytteoperasjon skjer enn tiltenkt, noe som vil endre verdier i rammedataene på en uventet måte.

(Ref: OmniROM Gerrit)

3. [CVE-2015-3824]

En biggie! Denne er ekkel. Det er det stikk motsatte av dette siste problemet - et heltallsoverløp, der et heltall kan bli "for stort". Hvis du når 65535 (for eksempel) og ikke kan telle høyere, vil du rulle rundt og gå til 0 neste!

Hvis du tildeler minne basert på dette (som er det Stagefright gjør!), ville du ende opp med alt for lite minne tildelt i arrayen. Når data ble lagt inn i dette, ville det potensielt overskrive ikke-relaterte data med data som den skadelige filskaperen kontrollerte.

(Ref: OmniROM Gerrit)

4. [CVE-2015-3826]

Nok en ekkel en! Svært lik den siste - nok et heltallsoverløp, der en matrise (brukt som buffer) ville blitt for liten. Dette vil tillate urelatert minne å bli overskrevet, noe som igjen er dårlig. Noen som kan skrive data inn i minnet kan ødelegge andre data som ikke er relatert, og potensielt bruke dette til å få en kode de kontrollerer til å bli kjørt av telefonen din.

(Ref: OmniROM Gerrit)

5. [CVE-2015-3827]

Ganske lik disse siste. En variabel brukes når du hopper over noe minne, og denne kan gjøres negativ under en subtraksjon (som ovenfor). Dette vil resultere i en veldig stor "hopp"-lengde, overfylte en buffer, noe som gir tilgang til minne som ikke bør åpnes.

(Ref: OmniROM Gerrit)

Det er også noen (potensielt) relaterte rettelser som ser ut til å ha kommet inn i [Android] 5.1 også.

(Ref: OmniROM Gerrit)

Dette legger til sjekker for å stoppe problemer med en tidligere sikkerhetsfiks for å legge til grensesjekker, som i seg selv kan bli overfylt. I C lagres tall som kan representeres som en signert int. Ellers forblir de uendret under drift. I disse kontrollene kunne noen heltall blitt signert (i stedet for usignerte), noe som ville redusere deres maksimale verdi senere, og tillate et overløp.

(Ref: OmniROM Gerrit)

Noen flere heltallsunderflyter (hvor tallene er for lave, og deretter subtraksjon utføres på disse tallene, slik at de blir negative). Dette fører igjen til et stort antall, i stedet for et lite, og det forårsaker de samme problemene som ovenfor.

(Ref: OmniROM Gerrit)

Og til slutt, nok et heltallsoverløp. Samme som før, det er i ferd med å bli brukt andre steder, og det kan renne over.

(Ref: OmniROM Gerrit)"

Hvor alvorlig er Stagefright?

I henhold til blogg innlegg publisert av morselskapet, Zimperium Research Labs, avslører Stagefright-utnyttelsen potensielt 95 % av Android-enheter – omtrent 950 millioner – har dette sikkerhetsproblemet, da det påvirker enheter som kjører Android 2.2 og opp. For å gjøre vondt verre, er enheter før Jelly Bean 4.3 på den "verste risikoen", da disse ikke inneholder tilstrekkelige midler mot denne utnyttelsen.

Med hensyn til skaden som Stagefright kunne gjøre, bemerket pulser_g2:

[blockquote author="pulser_g2"]"I seg selv ville Stagefright gi tilgang til systembrukeren på telefonen. Du må omgå ASLR (address space layout randomization) for å faktisk misbruke det. Hvorvidt dette er oppnådd eller ikke er ukjent akkurat nå. Denne utnyttelsen lar "vilkårlig kode" kjøres på enheten din som system- eller mediebruker. De har tilgang til lyden og kameraet på enheten, og systembrukeren er et flott sted å starte en rotutnyttelse fra. Husker du alle de fantastiske root-utnyttelsene du brukte for å roote telefonen din?

De kan potensielt brukes stille for å få rot på enheten din! Han som har root eier telefonen. De måtte omgå SELinux, men TowelRoot klarte det, og PingPong har klart det også. Når de får root, er alt på telefonen din åpent for dem. Meldinger, nøkler osv."[/blockquote]Når vi snakker om verste scenarier, er det bare en MMS som trengs for å levere kode og utløse denne utnyttelsen. Brukeren trenger ikke engang å åpne meldingen ettersom mange meldingsapper forhåndsbehandler MMS før brukeren samhandler med den. Dette er forskjellig fra spyd-phishing-angrep, da brukeren kan være fullstendig uvitende om et vellykket angrep, og kompromittere alle nåværende og fremtidige data i telefonen.

Hva skiller Stagefright fra andre «massive sårbarheter»?

"Alle sårbarheter utgjør en viss risiko for brukerne. Denne er spesielt risikabel, siden hvis noen finner en måte å angripe den eksternt (som er mulig, hvis en vei rundt ASLR ble funnet), kan den utløses før du i det hele tatt innser at du er under angrep"

Eldre utnyttelser som Android Installer Hijacking, FakeID samt rotutnyttelser som TowelRoot og PingPong krever brukerinteraksjon på et tidspunkt for å bli utført. Selv om de fortsatt er "utnytter" i det faktum at mye skade kan oppstå hvis de brukes ondsinnet, er det fortsatt et faktum at Stagefright trenger teoretisk sett bare et offers mobilnummer for å gjøre telefonen om til en trojaner, og har derfor blitt viet så mye oppmerksomhet den siste tiden dager.

Android er imidlertid ikke helt prisgitt denne utnyttelsen. Lead Engineer for Android Security, Adrian Ludwig adresserte noen bekymringer i en Google+-innlegg:

[blockquote author="Adrian Ludwig"]"Det er vanlig, feilaktig antagelse om at enhver programvarefeil kan gjøres om til en sikkerhetsutnyttelse. Faktisk kan de fleste feilene ikke utnyttes, og det er mange ting Android har gjort for å forbedre disse oddsene...

En liste over noen av disse teknologiene som har blitt introdusert siden Ice Cream Sandwich (Android 4.0) er oppført her. Den mest kjente av disse heter Address Space Layout Randomization (ASLR), som ble fullstendig fullført i Android 4.1 med støtte for PIE (Position Independent Executables) og er nå på over 85 % av Android enheter. Denne teknologien gjør det vanskeligere for en angriper å gjette plasseringen av kode, som kreves for at de skal bygge en vellykket utnyttelse...

Vi sluttet ikke med ASLR, vi har også lagt til NX, FortifySource, Read-Only-Relocations, Stack Canaries og mer."[/blockquote]

Det kan imidlertid fortsatt ikke benektes at Stagefright er en alvorlig sak for fremtiden til Android, og som sådan blir tatt på alvor av de involverte interessentene. Stagefright fremhevet også de hvite elefantene i rommet – problemet med fragmentering og oppdateringer som endelig når forbrukeren.

Oppdateringsdilemmaet

Når vi snakker om oppdateringer, er det godt å se at OEM-er tar ansvar for brukernes sikkerhet, som mange har lovet å forbedre oppdateringsprosessen spesifikt for å inkludere sikkerhetsfikser og oppdateringer for utnyttelser som Stagefright.

Blant de første som ga ut en offisiell uttalelse, har Google lovet månedlige sikkerhetsoppdateringer (i tillegg til de planlagte OS- og plattformoppdateringene) for de fleste av Nexus-enhetene, inkludert den nesten 3 år gamle Nexus 4. Samsung har også fulgt etter ved å kunngjøre at de vil samarbeide med operatører og partnere for å implementere en månedlig sikkerhetsoppdateringsprogram men den klarte ikke å spesifisere enhetene og tidslinjedetaljene for denne implementeringen. Dette er interessant ettersom det nevner en "fast track"-tilnærming til sikkerhetsoppdateringer i samarbeid med operatører, så vi kan forvent hyppigere oppdateringer (riktignok sikkerhetsbasert, men forhåpentligvis vil det akselerere fastvareoppgraderinger også) på operatør enheter.

Andre OEM-er som blir med i flokken inkluderer LG som vil bli med månedlige sikkerhetsoppdateringer. Motorola har også annonsert liste over enheter som vil bli oppdatert med Stagefright-fikser, og listen inkluderer nesten alle enheter selskapet har laget siden 2013. Sony har også sagt det enhetene vil snart motta oppdateringene også.

For en gangs skyld kommer også operatører med oppdateringer. Sprint har avgitt en uttalelse at noen enheter allerede har mottatt Stagefright-oppdateringen, med flere enheter planlagt for oppdateringen. AT&T har også fulgt etter ved å utstede oppdateringen til noen enheter. Verizon har også utstedt oppdateringer, selv om dette er en langsom utrulling som prioriterer avanserte smarttelefoner som Galaxy S6 Edge og Note 4. T-Mobile Note 4 mottok også en Stagefright-oppdatering.

Som sluttbruker er det noen få forholdsregler som kan tas for å redusere sjansene dine for å bli angrepet. For det første, deaktiver automatisk henting av MMS-meldinger i meldingsappene på telefonen din. Dette bør holde kontroll på tilfeller der ingen brukerinteraksjon var nødvendig for at utnyttelsen skulle fungere. Etter dette, pass på å unngå å laste ned media fra MMS-meldinger fra ukjente og ikke-klarerte kilder.

Som en XDA strømbruker kan du også Gjør endringer på byggerekvisitten din for å deaktivere Stagefright. Dette er ikke en fullstendig og sikker måte å redde deg selv fra Stagefright på, men du kan ta sjansen på å redusere sannsynligheten for et vellykket angrep hvis du sitter fast på en eldre Android-konstruksjon. Det finnes også tilpassede ROM-løsninger, hvorav de fleste synkroniserer kilder med AOSP regelmessig, og vil derfor ha Stagefright-fiksene integrert. Hvis du kjører en AOSP-basert rom, anbefales det på det sterkeste at du oppdaterer til en nyere versjon av ROMen som inneholder Stagefright-patchene. Du kan bruke denne appen for å sjekke om din nåværende daglige sjåfør er påvirket av Stagefright.

Android, Post-Stagefright

Stagefright har ikke vært annet enn en vekker til Android og dets problem med fragmentering samt oppdateringer. Det fremhever hvordan det ikke er noen klar mekanisme som gjør at slike kritiske rettelser kan rulles ut i tide til en rekke enheter. Mens OEM-er prøver å rulle ut oppdateringer for enheter, er den harde sannheten at de fleste av disse rettelsene vil være begrenset til kun nyere flaggskip. Andre ikke-flaggskip og eldre enheter, mye mindre fra mindre OEM-er, vil fortsette å bli utsatt for lignende Stagefright.

Det er en sølv lining til denne utnyttelsen: Den trakk oppmerksomhet på nytt over Androids oppdateringsprosess og satte den i et lys som ikke vil tiltrekke like mange fremtidige bedriftsbedrifter mot å ta i bruk Android for bedriftsbruk. Etter hvert som Google jobber mot større bedriftsadopsjon, vil den bli tvunget til å revurdere oppdateringsstrategien og mengden kontroll den tillater OEM-er.

Med Android M som kommer nærmere markedet for hver dag, ville det ikke være noen overraskelse om Google valgte å bryte ut flere og flere komponenter av AOSP til fordel for sin Play-tjenestepakke. Tross alt er det et område som Google fortsatt har full kontroll over hvis en enhet skal sendes med Google Play Store. Dette har sine egne ulemper i form av å erstatte åpne områder med tette vegger.

Når man spekulerer i fremtiden til Android, er det en (veldig liten) mulighet for at Google også kan begrense endringene som OEM-er kan gjøre for AOSP. Med RRO rammeverk Når de er tilstede i en funksjonell tilstand i Android M, kan Google begrense OEM-er til kun å gjøre kosmetiske endringer i form av RRO-skinn. Dette burde muliggjøre raskere oppdateringsdistribusjon, men vil gå på bekostning av OEM-er blir nektet muligheten til å tilpasse Android fullt ut.

En annen rute som kan være en mulighet er å gjøre det obligatorisk for alle enheter som sendes med Google Play Store for å motta garanterte sikkerhetsoppdateringer for en fast tidsperiode, muligens to år. Play Services-rammeverket kan brukes til å sjekke for tilstedeværelsen av viktige sikkerhetsoppdateringer og oppdateringer, med Play Butikk-tilgang som kan oppheves i tilfelle manglende overholdelse.

Avslutningsnotater

Dette er fortsatt spekulasjoner i beste fall, da det ikke er noen elegant måte å fikse dette problemet på. Bortsett fra en veldig totalitær tilnærming, vil det alltid være noen mangler i rekkevidden til rettelser. På grunn av det store antallet Android-enheter der ute, vil det være en veldig gigantisk oppgave å holde oversikt over statusen til hver enhets sikkerhet. Behovet for timen er en nytenkning av måten Android oppdaterer på, da den nåværende måten absolutt ikke er den beste. Vi i XDA Developers håper at Android fortsatt fortsetter å være tro mot sine Open-Source-røtter mens vi jobber sammen med Googles lukkede kildekode-planer.

Er telefonen din sårbar for Stagefright? Tror du telefonen din noen gang vil motta en Stagefright-oppdatering? Gi oss beskjed i kommentarene nedenfor!