Stagefright: Exploit, ktorý zmenil Android

Stagefright patrí medzi najhoršie zneužitie, aké Android v poslednej dobe videl. Kliknite, ak si chcete prečítať viac o špecifikách a vedieť, ako sa chrániť!

Jednou z najsilnejších stránok Androidu je predovšetkým jeho open source povaha, ktorá umožňuje zainteresovaným stranám forkovať, upravovať a redistribuovať OS spôsobom, ktorý vyhovuje ich konkrétnym potrebám. Ale práve táto výhoda open source pôsobí ako dvojsečná zbraň, pokiaľ ide o problémy so škodlivým softvérom a bezpečnosťou. Je jednoduchšie nájsť a opraviť nedostatky, keď máte veľa schopných prispievateľov na projekte, ktorého zdrojový kód je voľne dostupný. Oprava problému na úrovni zdroja sa však často nepremieta do toho, že problém bude vyriešený v rukách konečného spotrebiteľa. Android ako taký nie je prvou voľbou, pokiaľ ide o výber operačného systému pre podnikové potreby citlivé na údaje.

Spoločnosť Google na veľtrhu Google I/O 2014 prvýkrát posunula smerom k bezpečnejšiemu ekosystému, ktorý je pre podniky vhodnejší, a to spustením

Program Android For Work. Android For Work prijal pre potreby podniku dvojitý profilový prístup, pomocou ktorého môžu správcovia IT vytvoriť a odlišné užívateľské profily pre zamestnancov – jeden zameraný na prácu, ostatné profily sú pre zamestnancov osobné použitie. Vďaka použitiu hardvérového šifrovania a správou spravovaných politík zostali pracovné a osobné údaje oddelené a bezpečné. Následne si Android For Work získal väčšiu pozornosť v neskorších mesiacoch, pričom veľký dôraz sa kládol na zabezpečenie zariadenia proti malvéru. Plánoval to aj Google povoliť úplné šifrovanie zariadenia pre všetky zariadenia ktoré mali byť vydané s Androidom Lollipop hneď po vybalení, ale toto bolo zrušené kvôli problémom s výkonom, keďže implementácia tohto kroku bola pre výrobcov OEM voliteľná.

Presadzovanie bezpečného systému Android nie je úplne dielom spoločnosti Google, pretože spoločnosť Samsung v tom zohrala pomerne významnú úlohu Príspevky KNOX do AOSP, čo v konečnom dôsledku posilnený Android For Work. Nedávne bezpečnostné exploity a slabé miesta v systéme Android však poukazujú na náročnú úlohu, pokiaľ ide o popularitu pre podnikové prijatie. Príkladom je nedávna zraniteľnosť Stagefright.

Obsah:

  • Čo je to Stagefright?
  • Ako vážne je Stagefright?
  • Čím sa Stagefright líši od iných „obrovských zraniteľností“?
  • Dilema aktualizácie
  • Android, Post-Stagefright
  • Záverečné poznámky

Čo je to Stagefright?

Jednoducho povedané, Stagefright je exploit, ktorý využíva knižnicu kódov na prehrávanie médií v systéme Android s názvom libstagefright. Motor libstagefright sa používa na spustenie kódu, ktorý sa dostane vo forme škodlivého videa cez MMS, takže na úspešný útok je potrebné iba mobilné číslo obete.

Oslovili sme nášho interného odborníka, XDA Senior Recognized Developer a Developer Admin pulser_g2 poskytnúť podrobnejšie vysvetlenie.

"Keď toto píšem, zneužitie [Stagefright] malo byť vysvetlené na BlackHat [Link], hoci zatiaľ nie sú k dispozícii žiadne diapozitívy ani podrobnosti o bielej knihe.

Preto uvádzam toto vysvetlenie skôr ako hrubú predstavu o tom, čo sa deje, než ako veľmi podrobné vysvetlenie s plnou presnosťou atď.

Existuje množstvo rôznych chýb, ktoré tvoria Stagefright, a tieto majú svoje vlastné CVE [Bežné chyby zabezpečenia a vystavenia] čísla na sledovanie:

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

Bohužiaľ dostupné záplaty nie sú prepojené priamo s každým CVE (ako by mali byť), takže vysvetľovanie bude trochu chaotické.

1. [CVE-2015-1538]

V kóde spracovania MPEG4 je kód spracovania metadát 3GPP (veci, ktoré popisujú formát a ďalšie ďalšie informácie, keď je video vo formáte 3GPP) chybný. Neodmietla metadáta, kde boli údaje príliš veľké, skôr len skontrolovala, či nie sú príliš malé. To znamenalo, že útočník mohol vytvoriť „upravený“ alebo „poškodený“ súbor, ktorý by mal dlhšiu časť metadát, ako by mal.

Jednou z veľkých výziev pri písaní kódu na spracovanie „nedôveryhodných“ údajov (t. j. od používateľa alebo z akéhokoľvek iného miesta mimo vášho kódu) je spracovanie údajov s premenlivou dĺžkou. Videá sú toho dokonalým príkladom. Softvér potrebuje dynamicky prideľovať pamäť v závislosti od toho, čo sa deje.

V tomto prípade je vyrovnávacia pamäť vytvorená ako ukazovateľ na nejakú pamäť, ale dĺžka poľa, na ktorú ukazuje, bola o jeden prvok príliš krátka. Metadáta sa potom načítali do tohto poľa a bolo možné, aby posledná položka v tomto poli nebola "nulová" (alebo nula). Je dôležité, aby posledná položka v poli bola nula, pretože tak softvér povie, že pole je dokončené. Tým, že bola posledná hodnota nenulová (keďže pole bolo potenciálne o jeden prvok príliš malé), škodlivý kód mohol prečítať iná časť kódu a načítať príliš veľa údajov. Namiesto toho, aby sa zastavil na konci tejto hodnoty, môže pokračovať v čítaní iných údajov, ktoré by čítať nemal.

(Odkaz: OmniROM Gerrit)

2. [CVE-2015-1539]

Najkratšia možná „veľkosť“ metadát by mala byť 6 bajtov, pretože ide o reťazec UTF-16. Kód vezme veľkosť celočíselnej hodnoty a odpočíta od nej 6. Ak by táto hodnota bola menšia ako 6, odčítanie by „preteklo“ a zalomilo by sa a skončili by sme s veľmi veľkým číslom. Predstavte si, že viete počítať napríklad len od 0 do 65535. Ak vezmete číslo 4 a odčítate 6, nemôžete ísť pod nulu. Takže sa vrátite na 65535 a počítajte odtiaľ. To je to, čo sa tu deje!

Ak bola prijatá dĺžka pod 6, mohlo by to viesť k nesprávnemu dekódovaniu snímok, pretože proces byteswap používa premennú len16, ktorej hodnota sa získa z výpočtu počnúc (veľkosť-6). Mohlo by to spôsobiť oveľa väčšiu operáciu výmeny, ako sa plánovalo, čo by neočakávaným spôsobom zmenilo hodnoty v údajoch rámca.

(Odkaz: OmniROM Gerrit)

3. [CVE-2015-3824]

Veľký kus! Tento je odporný. Je tu presný opak tohto posledného problému – pretečenie celého čísla, kde môže byť celé číslo „príliš veľké“. Ak dosiahnete 65535 (napríklad) a nemôžete počítať vyššie, otočili by ste sa a prešli na 0!

Ak prideľujete pamäť na základe tohto (čo robí Stagefright!), skončili by ste s príliš malým množstvom pamäte pridelenej v poli. Keď by sa do toho vložili údaje, potenciálne by to prepísalo nesúvisiace údaje údajmi, ktoré kontroloval tvorca škodlivého súboru.

(Odkaz: OmniROM Gerrit)

4. [CVE-2015-3826]

Ďalší škaredý! Veľmi podobné poslednému - ďalšie pretečenie celého čísla, kde by pole (používané ako vyrovnávacia pamäť) bolo príliš malé. To by umožnilo prepísať nesúvisiacu pamäť, čo je opäť zlé. Niekto, kto dokáže zapisovať údaje do pamäte, môže poškodiť iné údaje, ktoré nesúvisia, a potenciálne to využiť na to, aby váš telefón spustil nejaký kód, ktorý ovláda.

(Odkaz: OmniROM Gerrit)

5. [CVE-2015-3827]

Celkom podobné ako tieto posledné. Premenná sa používa pri preskakovaní niektorej pamäte, a to môže byť negatívne počas odčítania (ako vyššie). To by malo za následok veľmi veľkú dĺžku „preskočenia“, pretečenie vyrovnávacej pamäte, čo by umožnilo prístup k pamäti, ku ktorej by sa nemalo pristupovať.

(Odkaz: OmniROM Gerrit)

Existujú aj niektoré (potenciálne) súvisiace opravy, ktoré sa zrejme dostali aj do [Android] 5.1.

(Odkaz: OmniROM Gerrit)

Toto pridáva kontroly na zastavenie problémov s minulou bezpečnostnou opravou na pridanie kontrol hraníc, ktoré môžu byť preplnené. V C sú čísla, ktoré môžu byť reprezentované ako podpísané int, uložené ako podpísané int. Inak zostanú počas prevádzky nezmenené. Pri týchto kontrolách mohli byť niektoré celé čísla označené (a nie nepodpísané), čo by neskôr znížilo ich maximálnu hodnotu a umožnilo by pretečenie.

(Odkaz: OmniROM Gerrit)

Niektoré ďalšie celočíselné podtečenia (kde sú čísla príliš nízke a potom sa na týchto číslach vykoná odčítanie, čo im umožní dostať sa do záporu). To opäť vedie k veľkému počtu, a nie k malému, a to spôsobuje rovnaké problémy ako vyššie.

(Odkaz: OmniROM Gerrit)

A nakoniec ďalšie pretečenie celého čísla. Rovnako ako predtým, bude sa používať inde a môže pretekať.

(Odkaz: OmniROM Gerrit)"

Ako vážne je Stagefright?

Podľa príspevok v blogu publikoval materská výskumná spoločnosť, Zimperium Research Labs, využitie Stagefright potenciálne odhaľuje 95 % zariadení so systémom Android – približne 950 miliónov – má túto chybu zabezpečenia, pretože ovplyvňuje zariadenia so systémom Android 2.2 a hore. Aby toho nebolo málo, zariadenia pred verziou Jelly Bean 4.3 sú vystavené „najhoršiemu riziku“, pretože neobsahujú adekvátne opatrenia proti tomuto zneužitiu.

Pokiaľ ide o škody, ktoré by Stagefright mohol spôsobiť, pulser_g2 poznamenal:

[blockquote author="pulser_g2"]"Stagefright by sám o sebe umožnil prístup používateľovi systému na telefóne. Museli by ste obísť ASLR (randomizáciu rozloženia adresného priestoru), aby ste to skutočne zneužili. Či sa to podarilo alebo nie, nie je v súčasnosti známe. Tento exploit umožňuje spustiť „ľubovoľný kód“ na vašom zariadení ako používateľovi systému alebo média. Títo majú prístup k zvuku a fotoaparátu na zariadení a používateľ systému je skvelým miestom na spustenie rootovského exploitu. Pamätáte si všetky úžasné root exploity, ktoré ste použili na rootovanie telefónu?

Tie by mohli byť potenciálne v tichosti použité na získanie root na vašom zariadení! Ten, kto má root, vlastní telefón. Museli by obísť SELinux, ale to zvládol TowelRoot a zvládol to aj PingPong. Keď získajú root, všetko vo vašom telefóne je pre nich otvorené. Správy, kľúče atď.“[/blockquote]Keď hovoríme o najhorších scenároch, na doručenie kódu a spustenie tohto zneužitia je potrebná iba MMS. Používateľ správu ani netreba otvárať pretože veľa aplikácií na odosielanie správ predbežne spracováva MMS predtým, ako s ňou používateľ interaguje. Toto sa líši od útokov typu spear-phishing, pretože používateľ môže úplne zabúdať na úspešný útok a ohroziť všetky súčasné a budúce údaje v telefóne.

Čím sa Stagefright líši od iných „obrovských zraniteľností“?

„Všetky zraniteľnosti predstavujú určité riziko pre používateľov. Toto je obzvlášť riskantné, pretože ak niekto nájde spôsob, ako naň zaútočiť na diaľku (čo je možné, ak by sa našiel spôsob, ako obísť ASLR), môže sa spustiť skôr, ako si vôbec uvedomíte, že ste pod útok"

Staršie exploity ako Android Installer Hijacking, FakeID, ako aj root exploity ako TowelRoot a PingPong si vyžadujú interakciu používateľa, aby mohli byť spustené. Aj keď stále „využívajú“ skutočnosť, že pri zlom použití môže vzniknúť veľa škody, faktom zostáva, že Stagefright teoreticky potrebuje iba mobilné číslo obete, aby zmenil svoj telefón na trójsky kôň, a preto sa mu v poslednej dobe venuje toľko pozornosti dni.

Android však nie je úplne vydaný na milosť a nemilosť tohto exploitu. Vedúci inžinier bezpečnosti systému Android Adrian Ludwig sa vyjadril k niektorým problémom v a príspevok Google+:

[blockquote author="Adrian Ludwig"]"Existuje bežný, mylný predpoklad, že akákoľvek softvérová chyba sa môže zmeniť na bezpečnostný exploit. V skutočnosti väčšina chýb nie je zneužiteľná a existuje veľa vecí, ktoré Android urobil na zlepšenie týchto šancí...

Zoznam niektorých technológií, ktoré boli zavedené od Ice Cream Sandwich (Android 4.0), sú uvedené tu. Najznámejší z nich sa nazýva Address Space Layout Randomization (ASLR), ktorý bol plne dokončený v systéme Android 4.1 s podporou PIE (Position Independent Executables) a je teraz na viac ako 85 % Androidu zariadení. Táto technológia sťažuje útočníkovi uhádnuť umiestnenie kódu, ktorý je potrebný na vytvorenie úspešného exploitu...

Neskončili sme s ASLR, pridali sme aj NX, FortifySource, Read-Only-Relocations, Stack Canaries a ďalšie.“[/blockquote]

Stále sa však nedá poprieť, že Stagefright je vážnou záležitosťou pre budúcnosť Androidu a ako taká ju zainteresované strany berú vážne. Stagefright tiež zdôraznila biele slony v miestnosti - problém fragmentácie a aktualizácií, ktoré sa konečne dostali k spotrebiteľovi.

Dilema aktualizácie

Keď už hovoríme o aktualizáciách, je dobré vidieť, že výrobcovia OEM preberajú zodpovednosť za bezpečnosť používateľov, ako mnohí sľúbili vylepšite proces aktualizácie špeciálne na začlenenie bezpečnostných opráv a záplat pre exploity ako Stagefright.

Medzi prvými, ktorí zverejnili oficiálne vyhlásenie, sľúbil Google mesačné bezpečnostné aktualizácie (okrem plánovaných aktualizácií operačného systému a platforiem) pre väčšinu svojich zariadení Nexus vrátane takmer 3-ročného Nexus 4. Samsung tiež nasledoval tento príklad a oznámil, že bude spolupracovať s operátormi a partnermi na implementácii a mesačný program bezpečnostných aktualizácií nedokázala však špecifikovať zariadenia a podrobnosti o časovej osi tejto implementácie. Je to zaujímavé, pretože sa v ňom spomína „rýchly“ prístup k aktualizáciám zabezpečenia v spolupráci s operátormi, takže môžeme očakávajte častejšie aktualizácie (aj keď založené na bezpečnosti, ale dúfajme, že to urýchli aj aktualizácie firmvéru) u operátora zariadení.

Medzi ďalších OEM, ktorí sa pripoja k balíku, patrí spoločnosť LG, ktorá sa pripojí mesačné bezpečnostné aktualizácie. Spoločnosť Motorola tiež oznámila zoznam zariadení, ktoré sa budú aktualizovať s opravami Stagefright a zoznam obsahuje takmer všetky zariadenia, ktoré spoločnosť vyrobila od roku 2013. Povedala to aj Sony jeho zariadenia čoskoro dostanú záplaty tiež.

Tentoraz prichádzajú s aktualizáciami aj operátori. Sprint má vydal vyhlásenie že niektoré zariadenia už dostali opravu Stagefright, pričom aktualizácia je naplánovaná na ďalšie zariadenia. AT&T tiež nasledovala príklad vydaním záplaty na niektoré zariadenia. Verizon tiež vydal opravy, aj keď ide o pomalé zavádzanie, ktoré uprednostňuje špičkové smartfóny, ako sú Galaxy S6 Edge a Note 4. T-Mobile Note 4 dostal aj aktualizáciu opravy Stagefright.

Ako koncový používateľ existuje niekoľko preventívnych krokov, ktoré môžete podniknúť, aby ste znížili svoje šance na napadnutie. Na začiatok vypnite automatické načítanie správ MMS v aplikáciách na odosielanie správ vo vašom telefóne. To by malo mať pod kontrolou prípady, keď na fungovanie exploitu nebola potrebná žiadna interakcia používateľa. Potom dávajte pozor, aby ste sa vyhli sťahovaniu médií z MMS správ z neznámych a nedôveryhodných zdrojov.

Ako výkonný používateľ XDA môžete tiež vykonajte úpravy vo svojej zostave, aby ste deaktivovali Stagefright. Toto nie je úplný a spoľahlivý spôsob, ako sa zachrániť pred Stagefright, ale môžete využiť svoje šance na zníženie pravdepodobnosti úspešného útoku, ak ste uviazli na staršej zostave systému Android. Existujú aj vlastné riešenia ROM, z ktorých väčšina pravidelne synchronizuje zdroje s AOSP, a preto budú mať zahrnuté opravy Stagefright. Ak používate ROM založenú na AOSP, dôrazne sa odporúča aktualizovať na novšie vydanie ROM, ktoré obsahuje opravy Stagefright. Môžeš použiť túto aplikáciu aby ste skontrolovali, či je váš aktuálny denný vodič ovplyvnený Stagefright.

Android, Post-Stagefright

Stagefright nebol ničím iným, len varovaním smerom k Androidu a jeho problému fragmentácie, ako aj aktualizácií. Zdôrazňuje, že neexistuje jasný mechanizmus, pomocou ktorého by sa takéto kritické opravy dali včas zaviesť do mnohých zariadení. Zatiaľ čo sa výrobcovia OEM snažia zavádzať opravy pre zariadenia, krutou pravdou je, že väčšina týchto opráv bude obmedzená iba na najnovšie vlajkové lode. Iné iné ako vlajkové lode a staršie zariadenia, oveľa menej od menších výrobcov OEM, budú naďalej vystavené podobným zariadeniam ako Stagefright.

Tento úlovok má striebornú hranicu: Znovu upriamila pozornosť na proces aktualizácie Androidu a postavila ho do svetla, ktoré nepritiahne toľko budúcich korporátnych spoločností, aby prijali Android na podnikové použitie. Keďže spoločnosť Google pracuje na lepšom podnikaní, bude nútená prehodnotiť svoju stratégiu aktualizácií a mieru kontroly, ktorú umožňuje výrobcom OEM.

Keďže Android M sa každým dňom blíži k uvedeniu na trh, nebolo by prekvapením, keby sa spoločnosť Google rozhodla odtrhnúť čoraz viac komponentov AOSP v prospech svojho balíka služieb Play. Koniec koncov, toto je jedna oblasť, nad ktorou má Google stále úplnú kontrolu, ak sa má zariadenie dodávať s Obchodom Google Play. Toto má svoje nevýhody vo forme nahradenia oblastí s otvoreným zdrojom stenami s blízkymi zdrojmi.

Pri špekuláciách o budúcnosti Androidu existuje (veľmi malá) možnosť, že Google môže tiež obmedziť zmeny, ktoré môžu výrobcovia OEM urobiť pre AOSP. S Rámec RRO Keďže je v systéme Android M prítomný vo funkčnom stave, Google by mohol výrobcom OEM obmedziť vykonávanie iba kozmetických zmien vo forme vzhľadov RRO. To by malo umožniť rýchlejšie nasadenie aktualizácií, ale bolo by to za cenu toho, že výrobcom OEM bude odopretá možnosť úplne prispôsobiť Android.

Ďalšou možnou cestou by bolo, aby bola povinná pre všetky zariadenia, s ktorými sa odosielajú Obchod Google Play bude dostávať zaručené aktualizácie zabezpečenia na pevne stanovené časové obdobie, možno dve rokov. Rámec Služieb Play by sa mohol použiť na kontrolu prítomnosti dôležitých bezpečnostných aktualizácií a opráv, pričom v prípade nesúladu bude prístup do Obchodu Play zrušený.

Záverečné poznámky

Toto je prinajlepšom stále špekulácia, pretože neexistuje žiadny elegantný spôsob, ako tento problém vyriešiť. Okrem veľmi totalitného prístupu bude vždy existovať nejaký nedostatok v dosahu opráv. Vzhľadom na obrovské množstvo zariadení so systémom Android by bolo sledovanie stavu zabezpečenia každého zariadenia veľmi obrovskou úlohou. Potreba tejto hodiny je prehodnotiť spôsob aktualizácie systému Android, pretože súčasný spôsob určite nie je najlepší. My v XDA Developers dúfame, že Android aj naďalej zostáva verný svojim koreňom Open-Source a zároveň spolupracuje s plánmi uzavretého zdroja Google.

Je váš telefón zraniteľný voči Stagefright? Myslíte si, že váš telefón niekedy dostane opravu Stagefright? Dajte nám vedieť v komentároch nižšie!