Stagefright: The Exploit That Changed Android

Az Android egyik legerősebb pontja elsősorban a nyílt forráskódú jellege, amely lehetővé teszi az érdekelt felek számára, hogy az operációs rendszert saját igényeiknek megfelelő módon alakítsák ki, módosítsák és újraterjeszthessék. De a nyílt forráskódnak ez az előnye kétélű fegyverként hat a rosszindulatú programokkal és a biztonsággal kapcsolatos kérdésekben. Könnyebb megtalálni és kijavítani a hibákat, ha sok hozzáértő közreműködő van egy projektben, amelynek forráskódja szabadon elérhető. A probléma forrásszintű megoldása azonban gyakran nem jelenti azt, hogy a probléma megoldása a végső fogyasztó kezében van. Mint ilyen, az Android nem a legfontosabb választás, amikor az operációs rendszert az adatérzékeny vállalati igényekhez kell választani.

A 2014-es Google I/O rendezvényen a Google az első lépést egy biztonságosabb és vállalkozásbarátabb ökoszisztéma felé tette a

Android For Work program. Az Android For Work egy ikerprofil-megközelítést alkalmazott a vállalati igényekhez, amellyel az informatikai rendszergazdák létrehozhattak egy különálló felhasználói profilok az alkalmazottak számára – az egyik a munkára összpontosít, a többi profilt pedig az alkalmazottak számára hagyja használat. A hardveralapú titkosítás és az adminisztrátor által felügyelt házirendek használatával a munkahelyi és a személyes adatok különállóak és biztonságosak maradtak. Ezt követően az Android For Work nagyobb figyelmet kapott a későbbi hónapokban, nagy hangsúlyt fektetve az eszköz rosszindulatú programokkal szembeni védelmére. A Google is ezt tervezte engedélyezze a teljes eszköztitkosítást minden eszközön amelyeket az Android Lollipop csomagból kellett volna kiadni, de ezt a teljesítményproblémák miatt törölték, mivel a lépést opcionálissá tették az OEM-ek számára.

A biztonságos Androidra való törekvés nem teljesen a Google munkája, hiszen ebben a Samsung igencsak jelentős szerepet játszott a maga révén A KNOX hozzájárulása az AOSP-hoz, ami végső soron megerősített Android For Work. Az Android legújabb biztonsági kihasználásai és sebezhetőségei azonban felfelé ívelő feladatra utalnak, amikor a vállalati alkalmazás népszerűsítéséről van szó. Ilyen például a közelmúltbeli Stagefright sebezhetőség.

Tartalom:

• Mi az a Stagefright?
• Mennyire komoly a Stagefright?
• Miben különbözik a Stagefright a többi "masszív sebezhetőségtől"?
• A frissítési dilemma
• Android, Post-Stagefright
• Záró megjegyzések

Mi az a Stagefright?

Egyszerűen fogalmazva, a Stagefright egy olyan kihasználás, amely a kódkönyvtárat használja az Android médialejátszásához libstagefright. A libstagefright motor olyan kód végrehajtására szolgál, amely MMS-en keresztül rosszindulatú videó formájában érkezik, így csak az áldozat mobilszámára van szükség a sikeres támadás végrehajtásához.

Megkerestük házon belüli szakértőnket, az XDA Senior Recognised Developert és a fejlesztői adminisztrátort. pulser_g2 részletesebb magyarázatot adni.

"Amikor ezt írom, a [Stagefright] kizsákmányolást a BlackHatnél kellett elmagyarázni [Link], bár még nem állnak rendelkezésre diák vagy fehér papírrészletek.

Ezért ezt a magyarázatot inkább csak hozzávetőleges elképzelésként adom, hogy mi történik, nem pedig egy nagyon mélyreható, teljes pontosságú magyarázatként stb.

A Stagefrightot számos különböző hiba alkotja, és ezeknek saját CVE-jük van [Gyakori sebezhetőségek és kitettségek] számok a követéshez:

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

Sajnos a rendelkezésre álló javítások nem kapcsolódnak közvetlenül az egyes CVE-ekhez (ahogyan kellene), így ezt kissé nehézkes lesz elmagyarázni.

1. [CVE-2015-1538]

Az MPEG4 kezelő kódban a 3GPP metaadat (a formátumot és egyéb extra infókat leíró cucc, ha egy videó 3GPP formátumú) kezelő kód hibás. Nem utasította el a metaadatokat, ahol az adatok túl nagyok voltak, inkább csak azt ellenőrizte, hogy túl kicsi-e. Ez azt jelentette, hogy a támadó létrehozhat egy "módosított" vagy "sérült" fájlt, amely a kelleténél hosszabb metaadat-résszel rendelkezik.

A „nem megbízható” adatok (azaz a felhasználótól vagy bármely más, a kódon kívüli helyről származó) adatok kezelésére vonatkozó kódírás egyik nagy kihívása a változó hosszúságú adatok kezelése. A videók tökéletes példák erre. A szoftvernek dinamikusan kell lefoglalnia a memóriát, attól függően, hogy mi történik.

Ebben az esetben egy puffer jön létre, mint egy memóriamutató, de annak a tömbnek a hossza, amelyre mutat, egy elemmel rövid volt. A metaadatok ezután beolvasásra kerültek ebbe a tömbbe, és lehetséges volt, hogy a tömb utolsó bejegyzése ne legyen "null" (vagy nulla). Fontos, hogy a tömb utolsó eleme nulla legyen, mivel a szoftver így jelzi, hogy a tömb befejeződött. Azáltal, hogy az utolsó értéket nullától eltérővé tudtuk tenni (mivel a tömb potenciálisan egy elemmel túl kicsi volt), a rosszindulatú kódot a kód egy másik része olvashatja, és túl sok adatot olvashat be. Ahelyett, hogy megállna ennek az értéknek a végén, folytathatja a beolvasást más adatokba, amelyeket nem kellene elolvasnia.

(Ref: OmniROM Gerrit)

2. [CVE-2015-1539]

A metaadatok lehető legrövidebb "mérete" 6 bájt legyen, mivel UTF-16 karakterláncról van szó. A kód felveszi az egész szám értékét, és levon belőle 6-ot. Ha ez az érték 6-nál kisebb, a kivonás "alulcsordul" és körbefutna, és nagyon nagy számot kapnánk. Képzeld el, ha például csak 0-tól 65535-ig tudsz számolni. Ha veszed a 4-et, és kivonod a 6-ot, nem mehetsz nulla alá. Tehát visszamész a 65535-re, és onnan számolsz. ez történik itt!

Ha 6 alatti hosszúságot vettünk, az a keretek helytelen dekódolásához vezethet, mivel a bájtcsere folyamat a len16 változót használja, amelynek értéke egy kezdetű számításból származik (6-os méret). Ez a szándékoltnál sokkal nagyobb swap műveletet okozhat, ami váratlan módon megváltoztatja a keretadatok értékeit.

(Ref: OmniROM Gerrit)

3. [CVE-2015-3824]

Egy nagyfiú! Ez csúnya. Ennek az utolsó problémának pont az ellentéte – egy egész szám túlcsordulása, ahol egy egész szám „túl nagyra” válhat. Ha eléred a 65535-öt (például), és nem tudsz feljebb számolni, akkor körbegurulsz, és legközelebb a 0-ra lépsz!

Ha ez alapján foglalod le a memóriát (ezt a Stagefright csinálja!), akkor túl kevés memóriát foglalsz le a tömbben. Amikor adatokat helyeztek ebbe, az esetleg felülírja a nem kapcsolódó adatokat a rosszindulatú fájl létrehozója által felügyelt adatokkal.

(Ref: OmniROM Gerrit)

4. [CVE-2015-3826]

Még egy csúnya! Nagyon hasonló az előzőhöz - egy másik egész túlcsordulás, ahol egy (pufferként használt) tömb túl kicsi lenne. Ez lehetővé tenné a nem kapcsolódó memória felülírását, ami ismét rossz. Valaki, aki tud adatokat írni a memóriába, megrongálhat más adatokat, amelyek nem kapcsolódnak egymáshoz, és ezt felhasználhatja arra, hogy az általa irányított kódot a telefonja fusson.

(Ref: OmniROM Gerrit)

5. [CVE-2015-3827]

Nagyon hasonló az utóbbiakhoz. Változót használunk, amikor átugorunk egy bizonyos memóriát, és ez negatívvá tehető a kivonás során (mint fent). Ez nagyon nagy "kihagyási" hosszt eredményezne, túlcsordulva a pufferen, hozzáférést biztosítva ahhoz a memóriához, amelyhez nem szabad hozzáférni.

(Ref: OmniROM Gerrit)

Vannak olyan (potenciálisan) kapcsolódó javítások is, amelyek úgy tűnik, hogy az [Android] 5.1-be is bekerültek.

(Ref: OmniROM Gerrit)

Ez ellenőrzéseket ad hozzá egy korábbi biztonsági javítással kapcsolatos problémák leállításához, és határellenőrzéseket ad hozzá, amelyek túlcsordulhatnak. A C-ben az előjeles intként ábrázolható számok előjeles intként vannak tárolva. Ellenkező esetben a működés során változatlanok maradnak. Ezekben az ellenőrzésekben egyes egész számokat előjelessé is lehetett volna tenni (nem pedig előjel nélküli), ami később csökkenti a maximális értéküket, és túlcsordulást tesz lehetővé.

(Ref: OmniROM Gerrit)

Még néhány egész alulcsordulás (ahol a számok túl alacsonyak, majd ezeken a számokon kivonás történik, ami lehetővé teszi, hogy negatívvá váljanak). Ez ismét nagy számhoz vezet, nem pedig kicsihez, és ez ugyanazokat a problémákat okozza, mint fent.

(Ref: OmniROM Gerrit)

És végül egy újabb egész szám túlcsordulás. Ugyanúgy, mint korábban, hamarosan máshol is használják, és túlcsordulhat.

(Ref: OmniROM Gerrit)"

Mennyire komoly a Stagefright?

Mint a blog bejegyzés az anyavállalat, a Zimperium Research Labs által közzétett Stagefright exploit potenciálisan leleplezi Az Android-eszközök 95%-a – nagyjából 950 millió – érinti ezt a sebezhetőséget, mivel ez érinti az Android 2.2 és fel. Tovább rontja a helyzetet, hogy a Jelly Bean 4.3 előtti eszközök a „legrosszabb kockázatnak” vannak kitéve, mivel ezek nem tartalmaznak megfelelő mérséklést ezzel a kizsákmányolással szemben.

A Stagefright által okozott károkkal kapcsolatban pulser_g2 megjegyezte:

[blockquote author="pulser_g2"]"Önmagában a Stagefright hozzáférést adna a rendszer felhasználójának a telefonon. Az ASLR-t (címterület-elrendezés véletlenszerűsítése) meg kell kerülnie, hogy ténylegesen visszaéljen vele. Hogy ez sikerült-e vagy sem, egyelőre nem tudni. Ez az exploit lehetővé teszi, hogy "tetszőleges kód" futtasson az eszközén rendszer- vagy médiafelhasználóként. Ezek hozzáférhetnek az eszköz hangjához és kamerájához, és a rendszer felhasználója remek hely a root exploit elindítására. Emlékszel az összes csodálatos root exploitra, amellyel a telefon rootolásához használtál?

Ezeket csendben fel lehet használni, hogy gyökeret szerezzen az eszközén! Akinek root van, az birtokolja a telefont. Ki kell kerülniük a SELinuxot, de a TowelRootnak ez sikerült, és a PingPongnak is sikerült. Amint megszerzik a root rendszert, minden a telefonodon nyitva áll előttük. Üzenetek, kulcsok stb."[/blockquote]Ha a legrosszabb forgatókönyvekről beszélünk, csak egy MMS-re van szükség a kód kézbesítéséhez és a kihasználáshoz. A felhasználó még az üzenetet sem kell megnyitnia mivel sok üzenetküldő alkalmazás előre feldolgozza az MMS-t, mielőtt a felhasználó kapcsolatba lépne vele. Ez különbözik az adathalász támadásoktól, mivel a felhasználó teljesen figyelmen kívül hagyhatja a sikeres támadást, ami veszélyezteti a telefonban lévő összes jelenlegi és jövőbeli adatot.

Miben különbözik a Stagefright a többi „masszív sebezhetőségtől”?

"Minden sebezhetőség bizonyos kockázatot jelent a felhasználók számára. Ez különösen kockázatos, mivel ha valaki megtalálja a módját, hogy távolról megtámadja (ami az lehetséges, ha sikerül megkerülnie az ASLR-t), akkor aktiválódhat, mielőtt észrevenné, hogy alatta van támadás"

A régebbi kihasználások, például az Android Installer Hijacking, a FakeID, valamint a root exploitok, mint a TowelRoot és a PingPong, bizonyos pontokon felhasználói beavatkozást igényelnek a végrehajtáshoz. Bár még mindig „kizsákmányolják” azt a tényt, hogy rosszindulatú felhasználás esetén sok kár származhat, a tény továbbra is fennáll, hogy a Stagefright elméletileg csak az áldozat mobilszámára van szüksége ahhoz, hogy telefonját trójaivá alakítsa, ezért az utóbbi időben nagy figyelmet szentelnek napok.

Az Android azonban nincs teljesen kiszolgáltatva ennek a kihasználásnak. Az Android Security vezető mérnöke, Adrian Ludwig aggodalmakkal foglalkozott a Google+-bejegyzés:

[blockquote author="Adrian Ludwig"]"Gyakori, téves feltételezés, hogy bármilyen szoftverhiba biztonsági kizsákmányolássá változtatható. Valójában a legtöbb hiba nem kihasználható, és az Android számos dolgot tett az esélyek javítása érdekében...

Az Ice Cream Sandwich (Android 4.0) óta bevezetett technológiák listája a listán található. itt. Ezek közül a legismertebb az Address Space Layout Randomization (ASLR), amely teljesen elkészült Android 4.1-ben a PIE (pozíciófüggetlen végrehajtható fájl) támogatásával, és már az Android több mint 85%-án eszközöket. Ez a technológia megnehezíti a támadók számára a kód helyének kitalálását, ami szükséges a sikeres kihasználáshoz...

Nem álltunk meg az ASLR-nél, hanem hozzáadtuk az NX-et, a FortifySource-t, a Read-Only-Relocations-t, a Stack Canaries-t és még sok mást."[/blockquote]

Azonban továbbra sem tagadható, hogy a Stagefright komoly kérdés az Android jövője szempontjából, és mint ilyen, az érintettek komolyan veszik. A Stagefright kiemelte a fehér elefántokat is a szobában – a töredezettség problémáját és azt, hogy a frissítések végül eljutnak a fogyasztóhoz.

A frissítési dilemma

Ha már a frissítéseknél tartunk, jó látni, hogy az OEM-ek felelősséget vállalnak a felhasználók biztonságáért, ahogy azt sokan megígérték, hogy javítja a frissítési folyamatot, kifejezetten a biztonsági javítások és javítások beépítésére az olyan kihasználásokhoz, mint a Stagefright.

A Google megígérte, hogy az elsők között tesz közzé hivatalos közleményt havi biztonsági frissítések (a tervezett operációs rendszer- és platformfrissítéseken kívül) a legtöbb Nexus készülékéhez, beleértve a csaknem 3 éves Nexus 4-et is. A Samsung is követte példáját, bejelentette, hogy együttműködik a szolgáltatókkal és partnerekkel az a havi biztonsági frissítési program de nem tudta megadni a megvalósítás eszközeit és idővonalának részleteit. Ez azért érdekes, mert megemlíti a biztonsági frissítések „gyorsított” megközelítését a szolgáltatókkal együttműködve, így gyakoribb frissítésekre számíthat (bár biztonsági alapú, de remélhetőleg felgyorsítja a firmware-frissítéseket is) a szolgáltatónál eszközöket.

A csomaghoz további OEM-gyártók is csatlakoznak, köztük az LG is, aki csatlakozni fog havi biztonsági frissítések. A Motorola is bejelentette a frissített eszközök listája Stagefright javításokkal, és a listán szinte az összes olyan eszköz szerepel, amelyet a cég 2013 óta gyártott. A Sony is ezt mondta készülékei hamarosan megkapják a javításokat is.

Az egyszer a szolgáltatók is frissítésekkel jelentkeznek. A Sprint rendelkezik közleményt adott ki hogy egyes eszközök már megkapták a Stagefright javítást, és több eszköz van ütemezve a frissítésre. Az AT&T is követte a példát a javítás kiadásával egyes eszközökre. A Verizon javításokat is kiadott, bár ez egy lassú bevezetés, amely előnyben részesíti az olyan csúcskategóriás okostelefonokat, mint a Galaxy S6 Edge és a Note 4. A T-Mobile Note 4 is kapott egy Stagefright patch frissítést.

Végfelhasználóként néhány elővigyázatossági lépést megtehet, hogy csökkentse a támadások esélyét. Kezdetben kapcsolja ki az MMS-üzenetek automatikus visszakeresését a telefonon található üzenetküldő alkalmazásokban. Ennek meg kell őriznie azokat az eseteket, amikor nem volt szükség felhasználói beavatkozásra a kihasználáshoz. Ezek után ügyeljen arra, hogy ne töltsön le médiát ismeretlen és nem megbízható forrásokból származó MMS-üzenetekből.

XDA-felhasználóként ezt is megteheti módosítsa az építményt a Stagefright letiltásához. Ez nem egy teljes és biztos módja annak, hogy megmentse magát a Stagefrighttól, de megragadhatja az esélyt, hogy csökkentse a sikeres támadás valószínűségét, ha egy régebbi Android-verziónál ragad. Vannak egyéni ROM-megoldások is, amelyek többsége rendszeresen szinkronizálja a forrásokat az AOSP-vel, így a Stagefright javításokat is beépítik. Ha AOSP alapú romot használ, erősen ajánlott frissíteni a ROM egy újabb kiadására, amely tartalmazza a Stagefright javításokat. Te tudod használni ezt az alkalmazást annak ellenőrzésére, hogy a Stagefright hatással van-e a jelenlegi napi vezetőjére.

Android, Post-Stagefright

A Stagefright nem más, mint egy ébresztő az Android felé, és annak töredezettségi problémája, valamint a frissítések. Rávilágít arra, hogy nincs egyértelmű mechanizmus, amely révén az ilyen kritikus javításokat időben ki lehet helyezni számos eszközre. Míg az OEM-ek javításokat próbálnak kihelyezni az eszközökhöz, a kemény igazság az, hogy ezeknek a javításoknak a többsége csak a legújabb zászlóshajókra korlátozódik. Más, nem zászlóshajók és régebbi eszközök, még kevésbé a kisebb OEM-ektől, továbbra is ki lesznek téve a Stagefright hasonlóinak.

Ezüst borítása van ennek a kihasználásnak: Újra felhívta a figyelmet az Android frissítési folyamatára, és olyan megvilágításba helyezte, amely nem vonzza majd annyi jövőbeni vállalati vállalatot az Android vállalati felhasználásra való átvétele felé. Ahogy a Google a nagyobb vállalati elterjedésen dolgozik, kénytelen lesz újragondolni frissítési stratégiáját és az OEM-ek számára lehetővé tévő ellenőrzés mértékét.

Mivel az Android M napról napra közeledik a piaci megjelenéshez, nem lenne meglepő, ha a Google úgy döntene, hogy az AOSP egyre több összetevőjét leválasztja a Play szolgáltatáscsomagja helyett. Végtére is, ez az a terület, amely felett a Google továbbra is teljes ellenőrzést gyakorol, ha egy eszközt a Google Play Áruházba kell szállítani. Ez megvannak a maga árnyoldalai nyílt forráskódú területek közeli forrású falakkal való helyettesítése formájában.

Az Android jövőjével kapcsolatos találgatások során (nagyon kicsi) fennáll annak a lehetősége, hogy a Google korlátozza az OEM-ek által az AOSP-n végrehajtott változtatásokat is. A... val RRO keretrendszer Mivel az Android M rendszerben működőképes állapotban van, a Google korlátozhatja az OEM-eket, hogy csak kozmetikai változtatásokat hajtsanak végre az RRO skinek formájában. Ez lehetővé tenné a frissítések gyorsabb telepítését, de ennek az az ára, hogy az OEM-ek megtagadják az Android teljes testreszabásának lehetőségét.

Egy másik lehetőség az lenne, ha kötelezővé tennék az összes szállított eszközre Google Play Áruház, ahol garantált biztonsági frissítéseket kaphat egy meghatározott időtartamra, esetleg kettőre évek. A Play Services keretrendszer használható a fontos biztonsági frissítések és javítások meglétének ellenőrzésére, és a Play Áruházhoz való hozzáférést visszavonják, ha nem megfelelő.

Záró megjegyzések

Ez a legjobb esetben is csak spekuláció, mivel nincs elegáns megoldás a probléma megoldására. A nagyon totalitárius megközelítéstől eltekintve mindig lesz némi hiányosság a javítások elérhetőségében. Az Android-eszközök nagy száma miatt az egyes eszközök biztonsági állapotának nyomon követése óriási feladat lenne. Az óra igénye az Android frissítési módjának újragondolása, mivel a jelenlegi mód biztosan nem a legjobb. Mi az XDA Developersnél reméljük, hogy az Android továbbra is hű marad nyílt forráskódú gyökereihez, miközben a Google zárt forráskódú tervei mentén dolgozik.

Sebezhető a telefonja a Stagefright-nak? Gondolod, hogy a telefonod kap valaha Stagefright javítást? Tudassa velünk az alábbi megjegyzésekben!