Stagefright: išnaudojimas, kuris pakeitė Android

Viena iš stipriausių „Android“ pusių visų pirma buvo atvirojo kodo pobūdis, leidžiantis suinteresuotosioms šalims pasirinkti, modifikuoti ir perskirstyti OS taip, kad ji atitiktų jų konkrečius poreikius. Tačiau šis atvirojo kodo pranašumas veikia kaip dviašmenis kardas, kai kalbama apie kenkėjiškų programų ir saugumo problemas. Lengviau rasti ir pataisyti trūkumus, kai projekte turite daug galinčių bendradarbių, kurių šaltinio kodas yra laisvai prieinamas. Tačiau problemos sprendimas šaltinio lygmeniu dažnai nereiškia, kad problema yra išspręsta galutinio vartotojo rankose. Todėl „Android“ nėra geriausias pasirinkimas, kai reikia pasirinkti OS, atitinkančią duomenims jautrius įmonės poreikius.

„Google I/O 2014“ parodoje „Google“ pirmą kartą pastūmėjo kurti saugesnę ir įmonėms palankesnę ekosistemą, pristatydama Android for Work programa

. „Android For Work“ taikė dviejų profilių metodą, skirtą įmonės poreikiams, pagal kuriuos IT administratoriai galėjo sukurti a atskiri vartotojų profiliai darbuotojams – vienas orientuotas į darbą, kiti profiliai paliekami darbuotojų asmeniniams naudoti. Naudojant aparatinės įrangos šifravimą ir administratoriaus tvarkomą politiką, darbo ir asmens duomenys išliko skirtingi ir saugūs. Vėliau „Android For Work“ sulaukė daugiau dėmesio vėlesniais mėnesiais, daugiausia dėmesio skiriant įrenginio apsaugai nuo kenkėjiškų programų. „Google“ taip pat planavo įgalinti visą įrenginio šifravimą visuose įrenginiuose kurie turėjo būti išleisti kartu su „Android Lollipop“, tačiau jie buvo išbraukti dėl našumo problemų, nes originalios įrangos gamintojams tai neprivaloma įdiegti.

Siekimas sukurti saugų „Android“ nėra visiškai „Google“ darbas, nes „Samsung“ suvaidino gana svarbų vaidmenį KNOX įnašai į AOSP, kuris galiausiai sustiprintas Android For Work. Tačiau naujausi „Android“ saugos išnaudojimai ir pažeidžiamumas rodo, kad verslas tampa vis populiaresnis. Pavyzdys yra naujausias „Stagefright“ pažeidžiamumas.

Turinys:

• Kas yra Stagefright?
• Kiek rimta yra „Stagefright“?
• Kuo „Stagefright“ skiriasi nuo kitų „didžiulių pažeidžiamumų“?
• Atnaujinimo dilema
• Android, Post-Stagefright
• Baigiamieji užrašai

Kas yra Stagefright?

Paprastai tariant, „Stagefright“ yra išnaudojimas, kuris naudoja kodų biblioteką medijos atkūrimui „Android“. libstagefright. Libstagefright variklis naudojamas vykdyti kodą, kuris gaunamas kaip kenkėjiškas vaizdo įrašas per MMS, todėl norint įvykdyti sėkmingą ataką, reikalingas tik aukos mobiliojo telefono numeris.

Susisiekėme su mūsų vidaus ekspertu, XDA vyresniuoju pripažintu kūrėju ir kūrėjo administratoriumi pulser_g2 pateikti išsamesnį paaiškinimą.

"Kai rašau tai, [Stagefright] išnaudojimas turėjo būti paaiškintas BlackHat [Nuoroda], nors skaidrių ar balto popieriaus detalių dar nėra.

Todėl šį paaiškinimą pateikiu labiau kaip apytikslį supratimą apie tai, kas vyksta, o ne kaip labai išsamų ir pilno tikslumo paaiškinimą ir pan.

Yra daugybė skirtingų „Stagefright“ klaidų ir jos turi savo CVE [Dažni pažeidžiamumai ir atvejai] sekimo numeriai:

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

Deja, galimos pataisos nėra tiesiogiai susietos su kiekvienu CVE (kaip turėtų būti), todėl tai bus šiek tiek nepatogu paaiškinti.

1. [CVE-2015-1538]

MPEG4 tvarkymo kode 3GPP metaduomenų (dalykų, apibūdinančių formatą ir kitą papildomą informaciją, kai vaizdo įrašas yra 3GPP formatu) tvarkymo kodas yra klaidingas. Ji neatmetė metaduomenų, kai duomenys buvo per dideli, o tik tikrino, ar jie per maži. Tai reiškė, kad užpuolikas galėjo sukurti „pakeistą“ arba „sugadintą“ failą, kurio metaduomenų dalis būtų ilgesnė nei turėtų.

Vienas iš didžiausių iššūkių rašant kodą, norint tvarkyti „nepatikimus“ duomenis (t. y. iš vartotojo ar bet kurios kitos vietos, nepriklausančios jūsų kodui), yra kintamo ilgio duomenų tvarkymas. Vaizdo įrašai yra puikus to pavyzdys. Programinė įranga turi dinamiškai paskirstyti atmintį, atsižvelgiant į tai, kas vyksta.

Šiuo atveju buferis sukuriamas kaip žymeklis į tam tikrą atmintį, tačiau masyvo, į kurį jis nukreipiamas, ilgis buvo vienu elementu per trumpas. Tada metaduomenys buvo nuskaityti į šį masyvą ir buvo įmanoma, kad paskutinis šio masyvo įrašas nebūtų „nulis“ (arba nulis). Svarbu, kad paskutinis masyvo elementas būtų lygus nuliui, nes taip programinė įranga praneša, kad masyvas baigtas. Sugebėjus padaryti paskutinę reikšmę nuliui (kadangi masyvas gali būti per mažas vienu elementu), kenkėjišką kodą gali nuskaityti kita kodo dalis ir perskaityti per daug duomenų. Užuot sustoję šios vertės pabaigoje, ji gali toliau skaityti kitus duomenis, kurių neturėtų skaityti.

(Nuoroda: OmniROM Gerrit)

2. [CVE-2015-1539]

Trumpiausias įmanomas metaduomenų "dydis" turėtų būti 6 baitai, nes tai yra UTF-16 eilutė. Kodas paima sveikojo skaičiaus reikšmės dydį ir iš jo atima 6. Jei ši vertė būtų mažesnė nei 6, atimtis „pertekėtų“ ir apvyniotų aplinką, o galų gale gautume labai didelį skaičių. Įsivaizduokite, kad, pavyzdžiui, galite suskaičiuoti tik nuo 0 iki 65535. Jei paimsite skaičių 4 ir atimsite 6, jūs negalite nukristi žemiau nulio. Taigi grįžkite į 65535 ir skaičiuokite nuo ten. Štai kas čia vyksta!

Jei gautas ilgis yra mažesnis nei 6, kadrai gali būti neteisingai iškoduoti, nes baitų apsikeitimo procesas naudoja kintamąjį len16, kurio reikšmė gaunama iš skaičiavimo, prasidedančio (dydis-6). Dėl to gali įvykti daug didesnė apsikeitimo operacija, nei numatyta, o tai netikėtai pakeis kadro duomenų vertes.

(Nuoroda: OmniROM Gerrit)

3. [CVE-2015-3824]

Didžiulis! Šis bjaurus. Yra visiškai priešinga šiai paskutinei problemai – sveikojo skaičiaus perpildymas, kai sveikas skaičius gali tapti „per didelis“. Jei pasieksite 65535 (pavyzdžiui) ir negalite skaičiuoti daugiau, apsiverstumėte ir eitumėte prie 0 toliau!

Jei paskirstysite atmintį remdamiesi tuo (būtent tai daro Stagefright!), masyve turėsite per mažai atminties. Įdėjus duomenis, nesusiję duomenys gali būti perrašyti duomenimis, kuriuos valdė kenkėjiškų failų kūrėjas.

(Nuoroda: OmniROM Gerrit)

4. [CVE-2015-3826]

Dar vienas bjaurus! Labai panašus į pastarąjį – dar vienas sveikųjų skaičių perpildymas, kur masyvas (naudojamas kaip buferis) būtų per mažas. Tai leistų perrašyti nesusijusią atmintį, o tai vėlgi yra blogai. Asmuo, galintis įrašyti duomenis į atmintį, gali sugadinti kitus nesusijusius duomenis ir galbūt panaudoti tai, kad jūsų telefonas paleistų tam tikrą jų valdomą kodą.

(Nuoroda: OmniROM Gerrit)

5. [CVE-2015-3827]

Visai panašus į šiuos paskutinius. Kintamasis naudojamas praleidžiant tam tikrą atmintį, o atėmimo metu jis gali būti neigiamas (kaip aukščiau). Dėl to atsirastų labai didelis „praleisti“ ilgis, perpildytas buferis ir būtų suteikta prieiga prie atminties, kuri neturėtų būti pasiekiama.

(Nuoroda: OmniROM Gerrit)

Taip pat yra keletas (galimai) susijusių pataisymų, kurie, atrodo, buvo įtraukti į [Android] 5.1.

(Nuoroda: OmniROM Gerrit)

Tai prideda patikrinimų, kad būtų sustabdytos problemos, susijusios su ankstesniu saugos pataisymu, kad būtų pridėta ribų patikra, kuri gali būti perpildyta. C kalboje skaičiai, kurie gali būti pavaizduoti kaip signed int, saugomi kaip signed int. Priešingu atveju operacijos metu jie išlieka nepakitę. Atliekant šiuos patikrinimus, kai kurie sveikieji skaičiai galėjo būti pažymėti (o ne nepasirašyti), o tai vėliau sumažintų maksimalią jų vertę ir leistų įvykti perpildymui.

(Nuoroda: OmniROM Gerrit)

Dar keli sveikieji skaičiai (kai skaičiai yra per maži, o tada iš tų skaičių atimama, todėl jie tampa neigiami). Tai vėlgi lemia didelį skaičių, o ne mažą, ir tai sukelia tas pačias problemas, kaip ir anksčiau.

(Nuoroda: OmniROM Gerrit)

Ir galiausiai, dar vienas sveikasis skaičius. Kaip ir anksčiau, jis bus naudojamas kitur ir gali perpildyti.

(Nuoroda: OmniROM Gerrit)"

Kiek rimta yra „Stagefright“?

Pagal tinklaraščio straipsnis patronuojančios tyrimų bendrovės Zimperium Research Labs paskelbtas Stagefright išnaudojimas gali atskleisti 95 % „Android“ įrenginių – maždaug 950 mln. – dėl šio pažeidžiamumo, nes jis veikia įrenginius, kuriuose veikia 2.2 ir 2. aukštyn. Dar blogiau, įrenginiams iki Jelly Bean 4.3 gresia „blogiausia rizika“, nes juose nėra tinkamų priemonių prieš šį išnaudojimą.

Kalbėdamas apie žalą, kurią galėjo padaryti Stagefright, pulser_g2 pažymėjo:

[blockquote author="pulser_g2"]"Pati Stagefright suteiktų prieigą sistemos vartotojui telefonu. Turėtumėte apeiti ASLR (adresų erdvės išdėstymo atsitiktinės atrankos), kad iš tikrųjų juo piktnaudžiautumėte. Ar tai buvo pasiekta, kol kas nežinoma. Šis išnaudojimas leidžia jūsų įrenginyje paleisti „savavališką kodą“ kaip sistemos ar medijos vartotojui. Jie turi prieigą prie įrenginio garso ir kameros, o sistemos vartotojas yra puiki vieta paleisti šakninį išnaudojimą. Prisimenate visus nuostabius root išnaudojimus, kuriuos naudojote norėdami įsišaknyti savo telefone?

Tai gali būti tyliai panaudota norint įgyti šaknį jūsų įrenginyje! Tas, kuris turi root, turi telefoną. Jie turėtų apeiti SELinux, bet „TowelRoot“ tai sugebėjo, o „PingPong“ taip pat sugebėjo. Kai jie įsišakniję, viskas, kas yra jūsų telefone, jiems bus atvira. Žinutės, raktai ir kt."[/blockquote]Kalbant apie blogiausius scenarijus, norint pateikti kodą ir suaktyvinti šį išnaudojimą, reikia tik MMS. Vartotojas net nereikia atidaryti pranešimo nes daugelis pranešimų programų iš anksto apdoroja MMS prieš vartotojui su ja sąveikaujant. Tai skiriasi nuo sukčiavimo sukčiavimo atakų, nes vartotojas gali visiškai pamiršti sėkmingą ataką ir pakenkti visiems esamiems ir būsimiems telefono duomenims.

Kuo „Stagefright“ skiriasi nuo kitų „didžiulių pažeidžiamumų“?

„Visi pažeidžiamumai kelia tam tikrą pavojų vartotojams. Tai ypač rizikinga, nes jei kas nors randa būdą užpulti jį nuotoliniu būdu (tai yra įmanoma, jei būtų rastas būdas apeiti ASLR), jis gali būti suaktyvintas net nesuvokiant, kad esate po žeme puolimas"

Senesni išnaudojimai, tokie kaip „Android Installer Hijacking“, „FakeID“, taip pat root išnaudojimai, tokie kaip „TowelRoot“ ir „PingPong“, tam tikru momentu reikalauja vartotojo sąveikos, kad būtų vykdomi. Nors jie vis dar yra „išnaudojimas“ tuo, kad piktybiškai panaudojus gali būti padaryta daug žalos, faktas lieka faktas, kad „Stagefright“ teoriškai reikia tik aukos mobiliojo telefono numerio, kad jo telefonas taptų Trojos arkliu, todėl pastaruoju metu jam skiriama tiek daug dėmesio dienų.

Tačiau „Android“ nėra visiškai priklausomas nuo šio išnaudojimo. Pagrindinis „Android“ saugos inžinierius Adrianas Ludwigas atkreipė dėmesį į kai kuriuos susirūpinimą keliančius klausimus „Google+“ įrašas:

[blockquote author="Adrian Ludwig"]"Yra paplitusi, klaidinga prielaida, kad bet kokia programinės įrangos klaida gali būti paversta saugumo išnaudojimu. Tiesą sakant, daugumos klaidų negalima išnaudoti ir yra daug dalykų, kuriuos „Android“ padarė, kad pagerintų šias galimybes...

Pateikiamas kai kurių technologijų, įdiegtų po Ice Cream Sandwich („Android 4.0“) sąrašas. čia. Labiausiai žinomas iš jų vadinamas Address Space Layout Randomization (ASLR), kuris buvo visiškai užbaigtas „Android 4.1“ su PIE (nuo pozicijos nepriklausomų vykdomųjų failų) palaikymu ir dabar yra daugiau nei 85 % „Android“ prietaisai. Dėl šios technologijos užpuolikui sunkiau atspėti kodo vietą, kuri reikalinga sėkmingam išnaudojimui...

Mes neapstojome su ASLR, taip pat įtraukėme NX, FortifySource, Read-Only-Relocations, Stack Canaries ir daugiau."[/blockquote]

Tačiau vis dar negalima paneigti, kad „Stagefright“ yra rimtas „Android“ ateities klausimas, todėl suinteresuotosios šalys į ją žiūri rimtai. Stagefright taip pat pabrėžė baltus dramblius kambaryje – susiskaidymo ir vartotoją galiausiai pasiekiančių atnaujinimų problemą.

Atnaujinimo dilema

Kalbant apie atnaujinimus, smagu matyti, kad originalios įrangos gamintojai prisiima atsakomybę už vartotojų saugumą, kaip daugelis pažadėjo patobulinti naujinimo procesą, specialiai įtraukiant saugos pataisas ir pataisas tokiems išnaudojimams kaip „Stagefright“.

„Google“ pažadėjo tarp pirmųjų, paskelbusių oficialų pareiškimą mėnesiniai saugos naujinimai (be planuojamų OS ir platformos atnaujinimų) daugumai „Nexus“ įrenginių, įskaitant beveik 3 metų senumo „Nexus 4“. „Samsung“ taip pat pasekė pavyzdžiu ir paskelbė, kad bendradarbiaus su operatoriais ir partneriais, kad įgyvendintų a mėnesinė saugos atnaujinimo programa tačiau nepavyko nurodyti šio įgyvendinimo įrenginių ir laiko juostos detalių. Tai įdomu, nes minimas „spartintas“ požiūris į saugos naujinimus bendradarbiaujant su operatoriais, todėl galime Tikėkitės, kad operatoriaus naujinimai bus dažnesni (nors ir pagrįsti saugumu, bet tikimės, kad tai taip pat pagreitins programinės įrangos atnaujinimus) prietaisai.

Kiti originalios įrangos gamintojai, prisijungę prie paketo, yra LG, kuris prisijungs prie paketo mėnesiniai saugos naujinimai. „Motorola“ taip pat paskelbė įrenginių, kurie bus atnaujinami, sąrašas su „Stagefright“ pataisymais, o sąraše yra beveik visi įrenginiai, kuriuos įmonė gamino nuo 2013 m. „Sony“ taip pat sakė jos įrenginiai netrukus gaus pataisas taip pat.

Kartą vežėjai taip pat laukia atnaujinimų. Sprintas turi paskelbė pareiškimą kad kai kurie įrenginiai jau gavo „Stagefright“ pataisą, o naujinimui numatyta daugiau įrenginių. AT&T taip pat pasekė pavyzdžiu kai kuriems įrenginiams išleisdamas pataisą. „Verizon“ taip pat išleido pataisas, nors tai yra lėtas diegimas, kuris teikia pirmenybę aukščiausios klasės išmaniesiems telefonams, tokiems kaip „Galaxy S6 Edge“ ir „Note 4“. „T-Mobile Note 4“ taip pat gavo „Stagefright“ pataisos atnaujinimą.

Kaip galutinis vartotojas, yra keletas atsargumo priemonių, kurių galite imtis, kad sumažintumėte tikimybę būti užpultam. Pirmiausia išjunkite automatinį MMS žinučių gavimą telefone esančiose pranešimų programose. Tai turėtų padėti kontroliuoti atvejus, kai naudotojo sąveika nebuvo reikalinga, kad išnaudojimas veiktų. Po to pasirūpinkite, kad neatsisiųstumėte medijos iš MMS pranešimų iš nežinomų ir nepatikimų šaltinių.

Kaip XDA energijos vartotojas, taip pat galite Redaguokite savo kūrimo rekvizitus, kad išjungtumėte „Stagefright“.. Tai nėra išsamus ir patikimas būdas apsisaugoti nuo „Stagefright“, tačiau galite pasinaudoti tikimybe, kad sumažintumėte sėkmingos atakos tikimybę, jei įstrigote prie senesnės „Android“ versijos. Taip pat yra pasirinktinių ROM sprendimų, kurių dauguma reguliariai sinchronizuoja šaltinius su AOSP, todėl bus įtraukti „Stagefright“ pataisymai. Jei naudojate AOSP pagrįstą ROM, labai rekomenduojama atnaujinti į naujesnę ROM versiją, kurioje yra Stagefright pataisos. Tu gali naudoti šią programą norėdami patikrinti, ar jūsų dabartinis kasdienis vairuotojas yra paveiktas „Stagefright“.

Android, Post-Stagefright

„Stagefright“ buvo ne kas kita, kaip „Android“ ir jos susiskaidymo bei atnaujinimų problema. Jame pabrėžiama, kad nėra aiškaus mechanizmo, pagal kurį tokius svarbius pataisymus būtų galima laiku įdiegti daugelyje įrenginių. Nors OĮG bando įdiegti įrenginių pataisas, šiurkšti tiesa yra ta, kad dauguma šių pataisymų apsiribos tik naujausiais flagmanais. Kiti ne flagmanai ir senesni įrenginiai, daug mažiau iš mažesnių originalios įrangos gamintojų, ir toliau bus veikiami kaip „Stagefright“.

Šiam išnaudojimui yra sidabrinis pamušalas: Tai iš naujo atkreipė dėmesį į „Android“ naujinimo procesą ir suteikė jam tokią šviesą, kuri nepritrauks tiek būsimų įmonių įmonių, kurios pradės naudoti „Android“ įmonės reikmėms. Kadangi „Google“ siekia didesnio pritaikymo įmonėms, ji bus priversta persvarstyti savo atnaujinimo strategiją ir OĮG leidžiamos kontrolės apimtis.

„Android M“ kasdien artėja prie išleidimo į rinką, todėl nenuostabu, kad „Google“ nuspręstų atskirti vis daugiau AOSP komponentų ir naudoti „Play“ paslaugų paketą. Galų gale, tai yra sritis, kurią „Google“ vis dar visiškai kontroliuoja, jei įrenginys bus pristatytas kartu su „Google Play“ parduotuve. Tai turi savų minusų atviro šaltinio plotų pakeitimas artimo šaltinio sienomis.

Spėliojant apie „Android“ ateitį, yra (labai maža) tikimybė, kad „Google“ taip pat gali apriboti pakeitimus, kuriuos OĮG gali padaryti AOSP. Su RRO sistema Kadangi „Android M“ veikia funkcionaliai, „Google“ galėtų apriboti OĮG, kad jie atliktų tik kosmetinius RRO apvalkalo pakeitimus. Tai turėtų sudaryti sąlygas greičiau įdiegti naujinimą, tačiau tai kainuotų tai, kad originalios įrangos gamintojams nebus suteikta galimybė visiškai pritaikyti „Android“.

Kitas būdas, kuris gali būti įmanomas, būtų padaryti jį privalomą visiems gabenamiems įrenginiams „Google Play“ parduotuvę, kad gautumėte garantuotus saugos naujinimus fiksuotam laikotarpiui, galbūt dviem metų. „Play Services“ sistema gali būti naudojama norint patikrinti, ar nėra svarbių saugos naujinimų ir pataisų, o prieiga prie „Play“ parduotuvės panaikinama, jei nesilaikoma reikalavimų.

Baigiamieji užrašai

Tai geriausiu atveju vis dar yra spėlionės, nes nėra elegantiško būdo išspręsti šią problemą. Be labai totalitarinio požiūrio, taisant visada bus kokių nors trūkumų. Dėl daugybės „Android“ įrenginių, sekti kiekvieno įrenginio saugos būseną būtų labai milžiniška užduotis. Valandos poreikis yra persvarstyti „Android“ atnaujinimo būdą, nes dabartinis būdas tikrai nėra geriausias. Mes, XDA kūrėjai, tikimės, kad „Android“ ir toliau išliks ištikimas savo atvirojo kodo šaknims, dirbdamas kartu su „Google“ uždarojo kodo planais.

Ar jūsų telefonas yra pažeidžiamas „Stagefright“? Ar manote, kad jūsų telefonas kada nors gaus „Stagefright“ pataisą? Praneškite mums toliau pateiktuose komentaruose!