Stagefright: Udnyttelsen, der ændrede Android

En af de stærkeste punkter ved Android har primært været dens open source-natur, som giver interessenter mulighed for at fordele, ændre og omfordele OS på en måde, der passer til deres særlige behov. Men netop denne fordel ved at være open source virker som et tveægget sværd, når det kommer til problemerne med malware og sikkerhed. Det er nemmere at finde og rette fejl, når du har mange dygtige bidragydere på et projekt, hvis kildekode er frit tilgængelig. Men at løse problemet på kildeniveau medfører ikke ofte, at problemet løses i hænderne på den endelige forbruger. Som sådan er Android ikke det førende valg, når det kommer til at vælge et OS til datafølsomme virksomhedsbehov.

Ved Google I/O 2014 gav Google sit første skub i retning af et mere sikkert og virksomhedsvenligt økosystem med lanceringen af Android For Work-program. Android For Work benyttede en dobbeltprofiltilgang til virksomhedsbehov, hvor it-administratorer kunne oprette en særskilte brugerprofiler for medarbejderne - en med fokus på arbejdet, mens andre profiler overlades til medarbejdernes personlige brug. Gennem brugen af ​​hardwarebaseret kryptering og admin-administrerede politikker forblev arbejds- og personlige data adskilte og sikre. Efterfølgende fik Android For Work mere opmærksomhed i de senere måneder, med stort fokus på enhedens sikkerhed mod malware. Google planlagde også

aktiver fuld enhedskryptering for alle enheder der skulle frigives med Android Lollipop ud af kassen, men dette blev skrottet på grund af ydeevneproblemer, da flytningen blev gjort valgfri for OEM'er at implementere.

Fremstødet for en sikker Android er ikke helt Googles arbejde, da Samsung har spillet en ret væsentlig rolle i dette via sin KNOX bidrag til AOSP, som i sidste ende styrket Android For Work. Nylige sikkerhedsudnyttelser og sårbarheder i Android peger dog på en op ad bakke opgave, når det kommer til popularitet for virksomhedsadoption. Et eksempel på dette er den nylige Stagefright-sårbarhed.

Indhold:

• Hvad er Stagefright?
• Hvor seriøs er Stagefright?
• Hvad gør Stagefright anderledes end andre "massive sårbarheder"?
• Opdateringsdilemmaet
• Android, Post-Stagefright
• Afsluttende noter

Hvad er Stagefright?

Enkelt sagt er Stagefright en udnyttelse, der bruger kodebiblioteket til medieafspilning i Android kaldet libstagefright. Libstagefright-motoren bruges til at udføre kode, som modtages i form af en ondsindet video via MMS, og kræver således kun offerets mobilnummer for at udføre et vellykket angreb.

Vi kontaktede vores interne ekspert, XDA Senior Recognized Developer og Developer Admin pulser_g2 for at give en mere detaljeret forklaring.

"Mens jeg skriver dette, skulle [Stagefright] udnyttelsen forklares på BlackHat [Link], selvom der endnu ikke er nogen dias eller hvide papirdetaljer tilgængelige.

Jeg giver derfor denne forklaring mere som en grov idé om, hvad der foregår, snarere end som en meget dybdegående forklaring med fuld nøjagtighed osv.

Der er en række forskellige fejl, der udgør Stagefright, og disse har deres egen CVE [Almindelige sårbarheder og eksponeringer] numre til sporing:

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

Desværre er de tilgængelige patches ikke knyttet direkte til hver CVE (som de burde være), så det vil være lidt rodet at forklare.

1. [CVE-2015-1538]

I MPEG4-håndteringskoden er håndteringskoden for 3GPP-metadata (de ting, der beskriver formatet og anden ekstra information, når en video er i 3GPP-format) fejlbehæftet. Den afviste ikke metadata, hvor dataene var for store, men kontrollerede kun, om de var for små. Dette betød, at det var muligt for en angriber at lave en "modificeret" eller "ødelagt" fil, som ville have en længere metadatadel, end den burde.

En af de store udfordringer ved at skrive kode for at håndtere "ikke-pålidelige" data (dvs. fra en bruger eller fra et hvilket som helst andet sted uden for din kode) er at håndtere data med variabel længde. Videoer er et perfekt eksempel på dette. Softwaren skal allokere hukommelse dynamisk, afhængigt af hvad der sker.

I dette tilfælde oprettes en buffer som en pointer til en eller anden hukommelse, men længden af ​​arrayet, den peger på, var et element for kort. Metadataene blev derefter læst ind i dette array, og det var muligt at få den sidste indgang i dette array til ikke at være "null" (eller nul). Det er vigtigt, at det sidste element i arrayet er nul, da det er sådan softwaren fortæller, at arrayet er færdigt. Ved at være i stand til at gøre den sidste værdi ikke-nul (da arrayet potentielt var et element for lille), kunne den ondsindede kode læses af en anden del af koden og indlæses for mange data. I stedet for at stoppe ved slutningen af ​​denne værdi, kan den blive ved med at læse ind i andre data, den ikke burde læse.

(Ref: OmniROM Gerrit)

2. [CVE-2015-1539]

Den kortest mulige "størrelse" af metadataene bør være 6 bytes, da det er en UTF-16-streng. Koden tager heltalsværdistørrelsen og trækker 6 fra den. Hvis denne værdi var mindre end 6, ville subtraktionen "flyde under" og pakkes rundt, og vi ville ende med et meget stort tal. Forestil dig, hvis du f.eks. kun kan tælle fra 0 til 65535. Hvis du tager tallet 4 og trækker 6 fra, kan du ikke gå under nul. Så du går tilbage til 65535 og tæller derfra. Det er, hvad der sker her!

Hvis en længde på under 6 blev modtaget, kan det føre til, at frames bliver forkert afkodet, da byteswap-processen bruger variablen len16, hvis værdi er opnået fra en beregning, der begynder med (størrelse-6). Dette kan forårsage, at der sker en meget større swap-operation end beregnet, hvilket ville ændre værdier i rammedataene på en uventet måde.

(Ref: OmniROM Gerrit)

3. [CVE-2015-3824]

En biggie! Den her er grim. Der er det stik modsatte af dette sidste problem - et heltalsoverløb, hvor et heltal kan blive "for stort". Hvis du når 65535 (for eksempel) og ikke kan tælle højere, vil du rulle rundt og gå til 0 næste!

Hvis du allokerer hukommelse baseret på dette (hvilket er hvad Stagefright gør!), ville du ende med at få alt for lidt hukommelse allokeret i arrayet. Når data blev lagt ind i dette, ville det potentielt overskrive ikke-relaterede data med data, som den ondsindede filopretter kontrollerede.

(Ref: OmniROM Gerrit)

4. [CVE-2015-3826]

Endnu en grim en! Meget lig den sidste - endnu et heltalsoverløb, hvor et array (brugt som buffer) ville blive gjort for lille. Dette ville gøre det muligt at overskrive ikke-relateret hukommelse, hvilket igen er dårligt. En person, der kan skrive data ind i hukommelsen, kan ødelægge andre data, der ikke er relateret, og potentielt bruge dette til at få en kode, de kontrollerer, til at blive kørt af din telefon.

(Ref: OmniROM Gerrit)

5. [CVE-2015-3827]

Meget lig de sidste. En variabel bruges, når man springer over noget hukommelse, og denne kan blive gjort negativ under en subtraktion (som ovenfor). Dette ville resultere i en meget stor "spring"-længde, overfyldte en buffer, hvilket giver adgang til hukommelse, der ikke bør tilgås.

(Ref: OmniROM Gerrit)

Der er også nogle (potentielt) relaterede rettelser, der ser ud til at have gjort det til [Android] 5.1.

(Ref: OmniROM Gerrit)

Dette tilføjer kontrol for at stoppe problemer med en tidligere sikkerhedsrettelse for at tilføje grænsekontrol, som i sig selv kan overskrides. I C er tal, der kan repræsenteres som en signeret int, gemt som en signeret int. Ellers forbliver de uændrede under driften. I disse kontroller kunne nogle heltal være blevet gjort signerede (i stedet for usignerede), hvilket ville reducere deres maksimale værdi senere og tillade et overløb at finde sted.

(Ref: OmniROM Gerrit)

Nogle flere heltal underløb (hvor tallene er for lave, og derefter subtraktion udføres på disse tal, så de bliver negative). Dette fører igen til et stort antal, snarere end et lille, og det forårsager de samme problemer som ovenfor.

(Ref: OmniROM Gerrit)

Og endelig, endnu et heltal overløb. Samme som før, det er ved at blive brugt andre steder, og det kan løbe over.

(Ref: OmniROM Gerrit)"

Hvor seriøs er Stagefright?

Som pr blogindlæg udgivet af moderforskningsselskabet, Zimperium Research Labs, afslører Stagefright-udnyttelsen potentielt 95 % af Android-enheder - omkring 950 millioner - til denne sårbarhed, da den påvirker enheder, der kører Android 2.2 og op. For at gøre tingene værre er enheder før Jelly Bean 4.3 i den "værste risiko", da disse ikke indeholder tilstrækkelige begrænsninger mod denne udnyttelse.

Med hensyn til den skade, som Stagefright kunne gøre, bemærkede pulser_g2:

[blockquote author="pulser_g2"]"I sig selv ville Stagefright give adgang til systembrugeren på telefonen. Du er dog nødt til at omgå ASLR (address space layout randomization) for rent faktisk at misbruge det. Hvorvidt dette er opnået, er uvist lige nu. Denne udnyttelse lader "vilkårlig kode" køres på din enhed som system- eller mediebruger. De har adgang til lyden og kameraet på enheden, og systembrugeren er et godt sted at starte en root-udnyttelse fra. Kan du huske alle de fantastiske root-udnyttelser, du brugte til at roote din telefon?

Disse kan potentielt stilles til brug for at få rod på din enhed! Den, der har rod, ejer telefonen. De skulle omgå SELinux, men TowelRoot klarede det, og PingPong har også formået. Når de får root, er alt på din telefon åbent for dem. Beskeder, nøgler osv."[/blockquote]Når vi taler om worst case-scenarier, er det kun nødvendigt med en MMS for at levere kode og udløse denne udnyttelse. Brugeren behøver ikke engang at åbne beskeden da en masse beskedapps forbehandler MMS, før brugeren interagerer med den. Dette er forskelligt fra spear-phishing-angreb, da brugeren kan være fuldstændig uvidende om et vellykket angreb og kompromittere alle nuværende og fremtidige data i telefonen.

Hvad gør Stagefright anderledes end andre "massive sårbarheder"?

"Alle sårbarheder udgør en vis risiko for brugerne. Denne er særlig risikabel, da hvis nogen finder en måde at angribe den på eksternt (som er muligt, hvis en vej uden om ASLR blev fundet), kunne den blive udløst, før du overhovedet opdager, at du er under angreb"

Ældre udnyttelser som Android Installer Hijacking, FakeID såvel som root exploits som TowelRoot og PingPong kræver brugerinteraktion på et tidspunkt for at blive udført. Selvom de stadig "udnytter" i det faktum, at en masse skade kan opstå, hvis de bruges ondsindet, er det stadig et faktum, at Stagefright teoretisk set kun har brug for et offers mobilnummer for at forvandle deres telefon til en trojaner og er derfor blevet givet så meget opmærksomhed i de seneste dage.

Android er dog ikke helt prisgivet denne udnyttelse. Lead Engineer af Android Security, Adrian Ludwig adresserede nogle bekymringer i en Google+ indlæg:

[blockquote author="Adrian Ludwig"]"Der er almindelig, fejlagtig antagelse om, at enhver softwarefejl kan omdannes til en sikkerhedsudnyttelse. Faktisk kan de fleste fejl ikke udnyttes, og der er mange ting Android har gjort for at forbedre disse odds...

En liste over nogle af de teknologier, der er blevet introduceret siden Ice Cream Sandwich (Android 4.0), er angivet her. Den mest kendte af disse hedder Address Space Layout Randomization (ASLR), som var fuldt gennemført i Android 4.1 med understøttelse af PIE (Position Independent Executables) og er nu på over 85 % af Android enheder. Denne teknologi gør det sværere for en angriber at gætte placeringen af ​​koden, som er nødvendig for, at de kan bygge en succesfuld udnyttelse...

Vi stoppede ikke med ASLR, vi har også tilføjet NX, FortifySource, Read-Only-Relocations, Stack Canaries og mere."[/blockquote]

Der kan dog stadig ikke benægtes, at Stagefright er en alvorlig sag for fremtiden for Android, og som sådan bliver taget alvorligt af de involverede interessenter. Stagefright fremhævede også de hvide elefanter i rummet - problemet med fragmentering og opdateringer, der endelig når frem til forbrugeren.

Opdateringsdilemmaet

Når vi taler om opdateringer, er det godt at se, at OEM'er tager ansvar for brugernes sikkerhed, som mange har lovet at forbedre opdateringsprocessen specifikt til inkorporering af sikkerhedsrettelser og patches til udnyttelser som Stagefright.

Blandt de første til at frigive en officiel erklæring, har Google lovet månedlige sikkerhedsopdateringer (ud over de planlagte OS- og platformopdateringer) for de fleste af deres Nexus-enheder, inklusive den næsten 3 år gamle Nexus 4. Samsung har også fulgt trop ved at annoncere, at de vil arbejde sammen med udbydere og partnere for at implementere en månedligt sikkerhedsopdateringsprogram men det lykkedes ikke at specificere enhederne og tidslinjedetaljerne for denne implementering. Dette er interessant, da det nævner en "fast track"-tilgang til sikkerhedsopdateringer i samarbejde med operatører, så vi kan Forvent hyppigere opdateringer (omend sikkerhedsbaseret, men forhåbentlig vil det også fremskynde firmwareopgraderinger) på operatøren enheder.

Andre OEM'er, der slutter sig til pakken, inkluderer LG, som vil slutte sig til månedlige sikkerhedsopdateringer. Motorola har også annonceret liste over enheder, der vil blive opdateret med Stagefright-rettelser, og listen omfatter næsten alle enheder, virksomheden har lavet siden 2013. Det har Sony også sagt dets enheder vil snart modtage patches også.

For en gangs skyld kommer udbydere også med opdateringer. Sprint har udsendt en erklæring at nogle enheder allerede har modtaget Stagefright-patchen, med flere enheder planlagt til opdateringen. AT&T har også fulgt trop ved at udstede patchen til nogle enheder. Verizon har også udgivet patches, selvom dette er en langsom udrulning, der prioriterer avancerede smartphones som Galaxy S6 Edge og Note 4. T-Mobile Note 4 modtog også en Stagefright patch-opdatering.

Som slutbruger er der et par forholdsregler, der kan tages for at mindske dine chancer for at blive angrebet. For det første skal du deaktivere automatisk hentning af MMS-beskeder i de beskedapps, der findes på din telefon. Dette skulle holde styr på de tilfælde, hvor der ikke var behov for brugerinteraktion for at udnyttelsen kunne virke. Efter dette skal du sørge for at undgå at downloade medier fra MMS-beskeder fra ukendte og upålidelige kilder.

Som en XDA power-bruger kan du også foretag redigeringer på din byggeprop for at deaktivere Stagefright. Dette er ikke en komplet og sikker måde at redde dig selv fra Stagefright, men du kan tage dine chancer for at mindske sandsynligheden for et vellykket angreb, hvis du sidder fast på en ældre Android-build. Der er også brugerdefinerede ROM-løsninger, hvoraf de fleste synkroniserer kilder med AOSP på en regelmæssig basis og derfor vil have Stagefright-rettelserne indarbejdet. Hvis du kører en AOSP-baseret rom, anbefales det stærkt, at du opdaterer til en nyere udgivelse af ROM'en, som inkorporerer Stagefright-patches. Du kan bruge denne app for at kontrollere, om din nuværende daglige chauffør er påvirket af Stagefright.

Android, Post-Stagefright

Stagefright har ikke været andet end et wake up call mod Android og dets problem med fragmentering samt opdateringer. Det fremhæver, hvordan der ikke er nogen klar mekanisme, ved hjælp af hvilken sådanne kritiske rettelser kan udrulles rettidigt til adskillige enheder. Mens OEM'er forsøger at udrulle patches til enheder, er den barske sandhed, at de fleste af disse rettelser kun vil være begrænset til de seneste flagskibe. Andre ikke-flagskibe og ældre enheder, meget mindre fra mindre OEM'er, vil fortsætte med at blive udsat for lignende Stagefright.

Der er en sølv linie til denne udnyttelse: Det gjorde igen opmærksom på Androids opdateringsproces og satte den i et lys, som ikke vil tiltrække så mange fremtidige virksomhedsvirksomheder til at adoptere Android til virksomhedsbrug. Efterhånden som Google arbejder hen imod større virksomhedsadoption, vil det være tvunget til at genoverveje sin opdateringsstrategi og mængden af ​​kontrol, det giver OEM'er.

Med Android M tættere på markedets udgivelse af dagen, ville det ikke være nogen overraskelse, hvis Google valgte at bryde flere og flere komponenter af AOSP væk til fordel for sin Play-tjenestepakke. Det er trods alt et område, som Google stadig har fuld kontrol over, hvis en enhed skal sendes med Google Play Butik. Det her har sine egne ulemper i form af at udskifte åbne områder med tæt kildevægge.

Når man spekulerer i fremtiden for Android, er der en (meget lille) mulighed for, at Google også kan begrænse de ændringer, som OEM'er kan gøre til AOSP. Med RRO ramme er til stede i en funktionel tilstand i Android M, kunne Google begrænse OEM'er til kun at foretage kosmetiske ændringer i form af RRO-skind. Dette skulle give mulighed for hurtigere opdateringsimplementering, men ville være på bekostning af, at OEM'er bliver nægtet muligheden for fuldt ud at tilpasse Android.

En anden rute, der kan være en mulighed, ville være at gøre det obligatorisk for alle enheder, der sendes med Google Play Butik for at modtage garanterede sikkerhedsopdateringer i en fast periode, muligvis to flere år. Play Services-rammen kunne bruges til at kontrollere tilstedeværelsen af ​​vigtige sikkerhedsopdateringer og patches, hvor adgangen til Play Butik tilbagekaldes i tilfælde af manglende overholdelse.

Afsluttende noter

Dette er i bedste fald stadig spekulation, da der ikke er nogen elegant måde at løse dette problem på. Bortset fra en meget totalitær tilgang, vil der altid være nogle mangler i rækkevidden af ​​rettelser. På grund af det store antal Android-enheder derude, ville det være en meget gigantisk opgave at holde styr på status for hver enheds sikkerhed. Behovet for timen er en gentænkning af den måde, Android opdaterer på, da den nuværende måde bestemt ikke er den bedste. Vi hos XDA Developers håber, at Android stadig fortsætter med at forblive tro mod sine Open Source-rødder, mens vi arbejder sammen med Googles lukkede kildeprogrammer.

Er din telefon sårbar over for Stagefright? Tror du, at din telefon nogensinde vil modtage en Stagefright-patch? Fortæl os det i kommentarerne nedenfor!