Stagefright: The Exploit That Changed Android

En av Androids starkaste sidor har främst varit dess öppen källkod, vilket gör det möjligt för intressenter att dela, modifiera och omfördela operativsystemet på ett sätt som passar deras specifika behov. Men just denna fördel med att vara öppen källkod fungerar som ett tveeggat svärd när det kommer till frågor om skadlig programvara och säkerhet. Det är lättare att hitta och korrigera brister när du har många duktiga bidragsgivare i ett projekt vars källkod är tillgänglig fritt. Att lösa problemet på källnivå leder dock inte ofta till att problemet åtgärdas i slutkonsumentens händer. Som sådan är Android inte det främsta valet när det gäller att välja ett operativsystem för datakänsliga företagsbehov.

På Google I/O 2014 gav Google sin första push mot ett säkrare och företagsvänligare ekosystem med lanseringen av Android For Work-programmet

. Android For Work antog en dubbelprofilsmetod för företagsbehov, där IT-administratörer kunde skapa en distinkta användarprofiler för anställda - en fokuserad på arbetet, lämnar andra profiler för de anställdas personliga använda sig av. Genom användningen av hårdvarubaserad kryptering och adminhanterade policyer förblev arbets- och personliga uppgifter distinkta och säkra. Därefter fick Android For Work mer uppmärksamhet under de senare månaderna, med stort fokus på enhetens säkerhet mot skadlig programvara. Google planerade också aktivera fullständig enhetskryptering för alla enheter som skulle släppas med Android Lollipop ur lådan, men detta skrotades på grund av prestandaproblem och flytten gjordes valfri för OEM att implementera.

Strävan efter en säker Android är inte helt Googles verk, eftersom Samsung har spelat en ganska betydande roll i detta via sin KNOX-bidrag till AOSP, vilket i slutändan stärkt Android For Work. Nya säkerhetsexploater och sårbarheter i Android pekar dock på en uppförsbacke när det kommer till popularitet för företagsintroduktion. Ett exempel är den senaste sårbarheten i Stagefright.

Innehåll:

• Vad är Stagefright?
• Hur seriös är Stagefright?
• Vad skiljer Stagefright från andra "massiva sårbarheter"?
• Uppdateringsdilemmat
• Android, Post-Stagefright
• Slutanteckningar

Vad är Stagefright?

Enkelt uttryckt är Stagefright en exploatering som använder kodbiblioteket för medieuppspelning i Android som kallas libstagefright. Libstagefright-motorn används för att exekvera kod som tas emot i form av en skadlig video via MMS, vilket kräver endast offrets mobilnummer för att utföra en framgångsrik attack.

Vi tog kontakt med vår interna expert, XDA Senior Recognized Developer och Developer Admin pulser_g2 för att ge en mer detaljerad förklaring.

"När jag skriver detta, skulle [Stagefright] exploateringen förklaras på BlackHat [Länk], även om det inte finns några bilder eller information om vitbok ännu.

Jag ger därför denna förklaring mer som en grov uppfattning om vad som händer, snarare än som en mycket djupgående förklaring med full noggrannhet etc.

Det finns ett antal olika buggar som utgör Stagefright, och dessa har sin egen CVE [Vanliga sårbarheter och exponeringar] nummer för spårning:

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

Tyvärr är de patchar som finns inte länkade direkt till varje CVE (som de borde vara), så det blir lite rörigt att förklara.

1. [CVE-2015-1538]

I MPEG4-hanteringskoden är hanteringskoden för 3GPP-metadata (de saker som beskriver formatet och annan extra information, när en video är i 3GPP-format) buggy. Den avvisade inte metadata, där data var överdrivet stor, utan kontrollerade bara om den var för liten. Detta innebar att det var möjligt för en angripare att skapa en "modifierad" eller "skadad" fil, som skulle ha en längre metadatadel än den borde.

En av de stora utmaningarna med att skriva kod för att hantera "otillförlitlig" data (dvs från en användare eller från någon annan typ av plats utanför din kod) är att hantera data med variabel längd. Videor är ett perfekt exempel på detta. Mjukvaran måste allokera minne dynamiskt, beroende på vad som händer.

I det här fallet skapas en buffert som en pekare till något minne, men längden på arrayen den pekar på var ett element för kort. Metadata lästes sedan in i denna array, och det var möjligt att den sista posten i denna array inte skulle vara "null" (eller noll). Det är viktigt att det sista objektet i arrayen är noll, eftersom det är så programvaran talar om att arrayen är klar. Genom att kunna göra det sista värdet icke-noll (eftersom arrayen potentiellt var ett element för litet), kunde den skadliga koden läsas av en annan del av koden och läsas in för mycket data. Istället för att stanna vid slutet av det här värdet kan den fortsätta läsa in annan data som den inte borde läsa.

(Ref: OmniROM Gerrit)

2. [CVE-2015-1539]

Kortast möjliga "storlek" på metadata bör vara 6 byte, eftersom det är en UTF-16-sträng. Koden tar heltalsvärdets storlek och subtraherar 6 från den. Om detta värde var mindre än 6, skulle subtraktionen "underflyta" och svepa runt, och vi skulle sluta med ett mycket stort tal. Tänk om du bara kan räkna från 0 till 65535 till exempel. Om du tar talet 4, och subtraherar 6, kan du inte gå under noll. Så du går tillbaka till 65535 och räknar därifrån. Det är vad som händer här!

Om en längd under 6 togs emot kan det leda till att ramar avkodas felaktigt, eftersom byteswap-processen använder variabeln len16, vars värde erhålls från en beräkning som börjar med (storlek-6). Detta kan göra att en mycket större växlingsoperation inträffar än avsett, vilket skulle ändra värden i ramdata på ett oväntat sätt.

(Ref: OmniROM Gerrit)

3. [CVE-2015-3824]

En biggie! Den här är otäck. Det finns raka motsatsen till den här sista frågan - ett heltalsspill, där ett heltal kan bli "för stort". Om du når 65535 (till exempel) och inte kan räkna högre, skulle du rulla runt och gå till 0 nästa!

Om du allokerar minne baserat på detta (vilket är vad Stagefright gör!), skulle du sluta med alldeles för lite minne tilldelat i arrayen. När data lades in i detta skulle det potentiellt skriva över orelaterade data med data som den skadliga filskaparen kontrollerade.

(Ref: OmniROM Gerrit)

4. [CVE-2015-3826]

Ännu en otäck sådan! Mycket lik den förra - ytterligare ett heltalsspill, där en array (används som buffert) skulle göras för liten. Detta skulle göra det möjligt för icke-relaterat minne att skrivas över, vilket återigen är dåligt. Någon som kan skriva data i minnet kan korrumpera annan data som inte är relaterad, och potentiellt använda detta för att få någon kod som de kontrollerar att köras av din telefon.

(Ref: OmniROM Gerrit)

5. [CVE-2015-3827]

Ganska lika de sistnämnda. En variabel används när man hoppar över något minne, och denna kan göras negativ under en subtraktion (som ovan). Detta skulle resultera i en mycket stor "hopp"-längd, som svämmar över en buffert, vilket ger tillgång till minne som inte bör nås.

(Ref: OmniROM Gerrit)

Det finns också några (potentiellt) relaterade korrigeringar som ser ut att ha kommit in i [Android] 5.1 också.

(Ref: OmniROM Gerrit)

Detta lägger till kontroller för att stoppa problem med en tidigare säkerhetsfix för att lägga till gränskontroller, som i sig kan svämma över. I C lagras nummer som kan representeras som en signerad int som en signerad int. Annars förblir de oförändrade under driften. I dessa kontroller kunde vissa heltal ha gjorts signerade (snarare än osignerade), vilket skulle minska deras maximala värde senare och tillåta ett spill att äga rum.

(Ref: OmniROM Gerrit)

Några fler heltalsunderflöden (där talen är för låga och sedan subtraktion utförs på dessa siffror, vilket gör att de blir negativa). Detta leder återigen till ett stort antal, snarare än ett litet, och det orsakar samma problem som ovan.

(Ref: OmniROM Gerrit)

Och slutligen, ytterligare ett heltalsspill. Samma som tidigare, det är på väg att användas någon annanstans, och det kan svämma över.

(Ref: OmniROM Gerrit)"

Hur seriös är Stagefright?

Enligt blogginlägg publicerat av moderföretaget Zimperium Research Labs, exponerar Stagefright exploateringen potentiellt 95 % av Android-enheterna – ungefär 950 miljoner – till denna sårbarhet eftersom den påverkar enheter som kör Android 2.2 och upp. För att göra saken värre löper enheter före Jelly Bean 4.3 den "värsta risken" eftersom dessa inte innehåller tillräckliga begränsningar mot detta utnyttjande.

När det gäller skadan som Stagefright kunde utsätta sig för, anmärkte pulser_g2:

[blockquote author="pulser_g2"]"I sig själv skulle Stagefright ge åtkomst till systemanvändaren på telefonen. Du måste dock kringgå ASLR (randomisering av adressutrymmeslayout) för att faktiskt missbruka det. Huruvida detta har uppnåtts eller inte är okänt just nu. Denna exploatering låter "godtycklig kod" köras på din enhet som system- eller mediaanvändare. De har tillgång till ljudet och kameran på enheten, och systemanvändaren är ett bra ställe att starta en rootexploat från. Kommer du ihåg alla de fantastiska rootexploaterna du använde för att rota din telefon?

Dessa kan potentiellt användas tyst för att få root på din enhet! Den som har root äger telefonen. De skulle behöva kringgå SELinux, men TowelRoot klarade det, och PingPong har också lyckats. När de får root är allt på din telefon öppet för dem. Meddelanden, nycklar, etc."[/blockquote]På tal om värsta scenarier behövs bara ett MMS för att leverera kod och utlösa detta utnyttjande. Användaren behöver inte ens öppna meddelandet eftersom många meddelandeappar förbehandlar MMS innan användaren interagerar med det. Detta skiljer sig från spear-phishing-attacker eftersom användaren kan vara helt omedveten om en framgångsrik attack och äventyra all nuvarande och framtida data i telefonen.

Vad skiljer Stagefright från andra "massiva sårbarheter"?

"Alla sårbarheter utgör en viss risk för användarna. Den här är särskilt riskabel, eftersom om någon hittar ett sätt att attackera den på distans (vilket är möjligt, om en väg runt ASLR hittades), kan den utlösas innan du ens inser att du är under ge sig på"

Äldre exploateringar som Android Installer Hijacking, FakeID såväl som rotexploater som TowelRoot och PingPong kräver användarinteraktion någon gång för att kunna köras. Även om de fortfarande "utnyttjar" det faktum att mycket skada kan uppstå om de används uppsåtligt, kvarstår faktum att Stagefright behöver teoretiskt sett bara ett offers mobilnummer för att förvandla sin telefon till en trojan och har därför fått så mycket uppmärksamhet på senare tid dagar.

Android är dock inte helt utlämnad till detta utnyttjande. Ledande ingenjör för Android Security, Adrian Ludwig tog upp några problem i en Google+ inlägg:

[blockquote author="Adrian Ludwig"]"Det finns vanliga, felaktiga antaganden att alla programvarufel kan förvandlas till en säkerhetsexploatering. Faktum är att de flesta buggar inte kan utnyttjas och det finns många saker Android har gjort för att förbättra dessa odds...

En lista över några av de tekniker som har introducerats sedan Ice Cream Sandwich (Android 4.0) är listade här. Den mest välkända av dessa kallas Address Space Layout Randomization (ASLR), som var helt färdig i Android 4.1 med stöd för PIE (Position Independent Executables) och finns nu på över 85 % av Android enheter. Den här tekniken gör det svårare för en angripare att gissa kodens plats, vilket krävs för att de ska kunna bygga en framgångsrik exploatering...

Vi slutade inte med ASLR, vi har även lagt till NX, FortifySource, Read-Only-Relocations, Stack Canaries och mer."[/blockquote]

Det går dock fortfarande inte att förneka att Stagefright är en allvarlig fråga för Androids framtid, och som sådan tas på allvar av de inblandade intressenterna. Stagefright lyfte också fram de vita elefanterna i rummet - problemet med fragmentering och att uppdateringar äntligen når konsumenten.

Uppdateringsdilemmat

På tal om uppdateringar är det bra att se att OEM: s tar ansvar för användarnas säkerhet, vilket många har lovat att förbättra uppdateringsprocessen specifikt för att införliva säkerhetsfixar och patchar för utnyttjande som Stagefright.

Bland de första att släppa ett officiellt uttalande har Google lovat månatliga säkerhetsuppdateringar (utöver de planerade OS- och plattformsuppdateringarna) för de flesta av sina Nexus-enheter, inklusive den nästan 3 år gamla Nexus 4. Samsung har också följt efter genom att meddela att de kommer att arbeta med operatörer och partners för att implementera en månatliga säkerhetsuppdateringsprogram men det gick inte att specificera enheter och tidslinjedetaljer för denna implementering. Detta är intressant eftersom det nämner en "snabbspår"-strategi för säkerhetsuppdateringar i samarbete med operatörer, så vi kan förvänta dig tätare uppdateringar (om än säkerhetsbaserade, men förhoppningsvis kommer det att påskynda uppgraderingar av firmware också) på operatören enheter.

Andra OEM-tillverkare som ansluter sig till paketet inkluderar LG som kommer att gå med månatliga säkerhetsuppdateringar. Motorola har också meddelat lista över enheter som kommer att uppdateras med Stagefright-fixar, och listan innehåller nästan alla enheter som företaget har gjort sedan 2013. Sony har också sagt det dess enheter kommer snart att få patchar för.

För en gångs skull kommer även operatörer med uppdateringar. Sprint har avgett ett uttalande att vissa enheter redan har fått Stagefright-patchen, med fler enheter planerade för uppdateringen. AT&T har också följt efter genom att utfärda patchen till vissa enheter. Verizon har också utfärdat patchar, även om detta är en långsam utrullning som prioriterar avancerade smartphones som Galaxy S6 Edge och Note 4. T-Mobile Note 4 fick också en Stagefright-patchuppdatering.

Som slutanvändare finns det några försiktighetsåtgärder som kan vidtas för att minska dina chanser att bli attackerad. Till att börja med, inaktivera automatisk hämtning av MMS-meddelanden i meddelandeapparna som finns på din telefon. Detta bör hålla kontroll över de fall där ingen användarinteraktion krävdes för att utnyttjandet skulle fungera. Efter detta, se till att undvika att ladda ner media från MMS-meddelanden från okända och opålitliga källor.

Som en XDA-användare kan du också gör ändringar på din byggpropp för att inaktivera Stagefright. Detta är inte ett komplett och säkert sätt att rädda dig själv från Stagefright, men du kan ta dina chanser att minska sannolikheten för en framgångsrik attack om du har fastnat på en äldre Android-version. Det finns också anpassade ROM-lösningar, varav de flesta synkroniserar källor med AOSP regelbundet och kommer därför att ha Stagefright-fixarna inbyggda. Om du kör en AOSP-baserad rom, rekommenderas det starkt att du uppdaterar till en nyare version av ROM som innehåller Stagefright-patcharna. Du kan använda den här appen för att kontrollera om din nuvarande dagliga förare påverkas av Stagefright.

Android, Post-Stagefright

Stagefright har inte varit något annat än en väckarklocka till Android och dess problem med fragmentering och uppdateringar. Det belyser hur det inte finns någon tydlig mekanism med hjälp av vilken sådana kritiska korrigeringar kan rullas ut i rätt tid till många enheter. Medan OEM-tillverkare försöker rulla ut patchar för enheter, är den hårda sanningen att de flesta av dessa korrigeringar kommer att vara begränsade till enbart nya flaggskepp. Andra icke-flaggskepp och äldre enheter, mycket mindre från mindre OEM: er kommer att fortsätta att exponeras för liknande Stagefright.

Det finns ett guldkant i denna bedrift: Den uppmärksammade Androids uppdateringsprocess på nytt och ställde den i ett ljus som inte kommer att locka lika många framtida företagsföretag att anta Android för företagsanvändning. När Google arbetar för ett större företagsintroduktion kommer det att tvingas ompröva sin uppdateringsstrategi och mängden kontroll som den tillåter OEM: s.

Med Android M närmar sig marknaden för varje dag, skulle det inte vara någon överraskning om Google valde att bryta bort fler och fler komponenter i AOSP till förmån för sitt Play-tjänstpaket. Det är trots allt ett område som Google fortfarande har fullständig kontroll över om en enhet ska skickas med Google Play Butik. Detta har sina egna nackdelar i form av att byta ut öppna ytor med täta väggar.

När man spekulerar i framtiden för Android finns det en (mycket liten) möjlighet att Google också kan begränsa de förändringar som OEM kan göra för AOSP. Med RRO ramverk Eftersom Google är närvarande i ett funktionellt tillstånd i Android M, kan Google begränsa OEM: s att endast göra kosmetiska ändringar i form av RRO-skinn. Detta bör möjliggöra snabbare uppdateringsdistribution, men skulle vara på bekostnad av OEM: s nekas möjligheten att helt anpassa Android.

En annan väg som kan vara en möjlighet skulle vara att göra det obligatoriskt för alla enheter som skickas med Google Play Butik för att få garanterade säkerhetsuppdateringar under en bestämd tidsperiod, eventuellt två år. Ramverket för Play Services skulle kunna användas för att kontrollera förekomsten av viktiga säkerhetsuppdateringar och patchar, där åtkomst till Play Butik återkallas i händelse av bristande efterlevnad.

Slutanteckningar

Detta är fortfarande spekulationer i bästa fall eftersom det inte finns något elegant sätt att lösa detta problem. Bortsett från ett mycket totalitärt tillvägagångssätt, kommer det alltid att finnas några brister i räckvidden för korrigeringar. På grund av det stora antalet Android-enheter där ute skulle det vara en väldigt gigantisk uppgift att hålla reda på statusen för varje enhets säkerhet. Timmens behov är en omprövning av hur Android uppdaterar eftersom det nuvarande sättet verkligen inte är det bästa. Vi på XDA Developers hoppas att Android fortfarande fortsätter att vara trogen sina rötter med öppen källkod samtidigt som vi arbetar tillsammans med Googles planer för stängd källkod.

Är din telefon sårbar för Stagefright? Tror du att din telefon någonsin kommer att få en Stagefright-patch? Låt oss veta i kommentarerna nedan!