Stagefright: ekspluatācija, kas mainīja Android

Stagefright ir viens no sliktākajiem Android ekspluatācijas veidiem, ko pēdējā laikā redzējis. Noklikšķiniet, lai uzzinātu vairāk par specifiku un uzzinātu, kā sevi pasargāt!

Viens no Android spēcīgākajiem aspektiem galvenokārt ir bijis tā atvērtā pirmkoda raksturs, kas ļauj ieinteresētajām personām sadalīt, modificēt un pārdalīt OS tādā veidā, kas atbilst viņu īpašajām vajadzībām. Taču šī atvērtā pirmkoda priekšrocība darbojas kā abpusgriezīgs zobens, kad runa ir par ļaunprātīgas programmatūras un drošības problēmām. Ir vieglāk atrast un novērst trūkumus, ja projektā ir daudz spējīgu atbalstītāju, kura pirmkods ir brīvi pieejams. Tomēr problēmas atrisināšana avota līmenī ne vienmēr nozīmē, ka problēma tiek atrisināta gala patērētāja rokās. Tādējādi Android nav galvenā izvēle, izvēloties OS datu jutīgām uzņēmuma vajadzībām.

Google I/O 2014. gadā Google sniedza pirmo impulsu drošākas un uzņēmumam draudzīgākas ekosistēmas izveidei, izlaižot Android for Work programma. Android For Work izmantoja divu profilu pieeju uzņēmuma vajadzībām, saskaņā ar kuru IT administratori varēja izveidot a atšķirīgi lietotāju profili darbiniekiem – viens koncentrējas uz darbu, atstājot citus profilus darbinieku personīgajiem izmantot. Izmantojot uz aparatūru balstītu šifrēšanu un administratoru pārvaldītas politikas, darba un personas dati palika atšķirīgi un droši. Pēc tam pēdējos mēnešos Android For Work tika pievērsta lielāka uzmanība, īpašu uzmanību pievēršot ierīces drošībai pret ļaunprātīgu programmatūru. To plānoja arī Google

iespējot pilnu ierīces šifrēšanu visām ierīcēm kuras bija paredzēts izlaist ar Android Lollipop komplektāciju, taču tas tika atcelts veiktspējas problēmu dēļ, kas oriģinālā aprīkojuma ražotājiem tika padarīts neobligāts.

Tiekšanās pēc drošas Android nav pilnībā Google darbs, jo Samsung ar savu palīdzību tajā spēlēja diezgan nozīmīgu lomu KNOX ieguldījums AOSP, kas galu galā pastiprināta Android For Work. Tomēr jaunākie drošības izmantošanas gadījumi un ievainojamības operētājsistēmā Android norāda uz augšupejošu uzdevumu, kad runa ir par uzņēmumu ieviešanas popularitāti. Piemērs ir nesenā Stagefright ievainojamība.

Saturs:

  • Kas ir Stagefright?
  • Cik nopietna ir Stagefright?
  • Ar ko Stagefright atšķiras no citām "masveida ievainojamībām"?
  • Atjaunināšanas dilemma
  • Android, Post-Stagefright
  • Noslēguma piezīmes

Kas ir Stagefright?

Vienkārši izsakoties, Stagefright ir izmantošana, kas izmanto kodu bibliotēku multivides atskaņošanai operētājsistēmā Android, ko sauc libstagefright. Libstagefright dzinējs tiek izmantots, lai izpildītu kodu, kas tiek saņemts ļaunprātīga video veidā, izmantojot MMS, tādējādi, lai veiktu veiksmīgu uzbrukumu, ir nepieciešams tikai upura mobilā tālruņa numurs.

Mēs sazinājāmies ar mūsu iekšējo ekspertu, XDA vecāko atzīto izstrādātāju un izstrādātāja administratoru. pulser_g2 lai sniegtu sīkāku skaidrojumu.

"Kamēr es rakstu, [Stagefright] ekspluatācija bija jāpaskaidro BlackHat [Saite], lai gan vēl nav pieejami slaidi vai balta papīra informācija.

Tāpēc es sniedzu šo skaidrojumu vairāk kā aptuvenu priekšstatu par notiekošo, nevis kā ļoti padziļinātu skaidrojumu ar pilnu precizitāti utt.

Ir vairākas dažādas kļūdas, kas veido Stagefright, un tām ir savs CVE [Izplatītas ievainojamības un ekspozīcijas] izsekošanas numuri:

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

Diemžēl pieejamie ielāpi nav tieši saistīti ar katru CVE (kā tiem vajadzētu būt), tāpēc to izskaidrot būs nedaudz netīri.

1. [CVE-2015-1538]

MPEG4 apstrādes kodā 3GPP metadatu (kas apraksta formātu un citu papildu informāciju, ja videoklips ir 3GPP formātā) apstrādes kods ir kļūdains. Tas nenoraidīja metadatus, kur dati bija pārāk lieli, bet tikai pārbaudīja, vai tie nav pārāk mazi. Tas nozīmēja, ka uzbrucējs varēja izveidot "modificētu" vai "bojātu" failu, kuram būtu garāka metadatu daļa, nekā vajadzētu.

Viens no lielākajiem izaicinājumiem, rakstot kodu, lai apstrādātu "neuzticamus" datus (t.i., no lietotāja vai jebkuras citas vietas ārpus jūsu koda), ir mainīga garuma datu apstrāde. Video ir lielisks piemērs tam. Programmatūrai ir dinamiski jāpiešķir atmiņa atkarībā no tā, kas notiek.

Šajā gadījumā buferis tiek izveidots kā norāde uz kādu atmiņu, bet masīva garums, uz kuru tas norāda, bija par vienu elementu par īsu. Pēc tam metadati tika nolasīti šajā masīvā, un bija iespējams, lai pēdējais ieraksts šajā masīvā nebūtu "nulle" (vai nulle). Ir svarīgi, lai pēdējais masīva vienums būtu nulle, jo tā programmatūra norāda, ka masīvs ir pabeigts. Ja pēdējā vērtība nav nulle (jo masīvs, iespējams, bija viens elements par mazu), ļaunprātīgo kodu varēja nolasīt cita koda daļa un nolasīt pārāk daudz datu. Tā vietā, lai apturētu šīs vērtības beigās, tas varētu turpināt lasīt citus datus, kurus tam nevajadzētu lasīt.

(Atsauce: OmniROM Gerrit)

2. [CVE-2015-1539]

Īsākajam iespējamajam metadatu "lielumam" jābūt 6 baitiem, jo ​​tā ir UTF-16 virkne. Kods ņem vesela skaitļa vērtības lielumu un no tā atņem 6. Ja šī vērtība būtu mazāka par 6, atņemšana "plūstu zem" un aplauztos, un mēs iegūtu ļoti lielu skaitli. Iedomājieties, ja jūs, piemēram, varat skaitīt tikai no 0 līdz 65535. Ja ņemat skaitli 4 un atņemat 6, jūs nevarat nokrist zem nulles. Tātad jūs atgriezīsities pie 65535 un skaitiet no turienes. Lūk, kas šeit notiek!

Ja tika saņemts garums, kas mazāks par 6, var tikt nepareizi atšifrēti kadri, jo baitu apmaiņas procesā tiek izmantots mainīgais len16, kura vērtība tiek iegūta no aprēķina, kas sākas ar (izmērs-6). Tas var izraisīt daudz lielāku mijmaiņas darbību, nekā paredzēts, kas negaidīti mainītu vērtības kadra datos.

(Atsauce: OmniROM Gerrit)

3. [CVE-2015-3824]

Lielnieks! Šis ir pretīgs. Ir tieši pretējs šai pēdējai problēmai - vesela skaitļa pārpilde, kur vesels skaitlis var kļūt "pārāk liels". Ja jūs sasniedzat 65535 (piemēram) un nevarat skaitīt vairāk, jūs apgrieztos un nākamais dotos uz 0!

Ja piešķirat atmiņu, pamatojoties uz to (to dara Stagefright!), masīvā tiktu piešķirts pārāk maz atmiņas. Kad tajā tika ievietoti dati, tie, iespējams, pārrakstītu nesaistītus datus ar datiem, ko kontrolēja ļaunprātīgā faila veidotājs.

(Atsauce: OmniROM Gerrit)

4. [CVE-2015-3826]

Vēl viens pretīgs! Ļoti līdzīgs pēdējam - vēl viena vesela skaitļa pārpilde, kur masīvs (izmantots kā buferis) būtu par mazu. Tas ļautu pārrakstīt nesaistītu atmiņu, kas atkal ir slikti. Persona, kas var ierakstīt datus atmiņā, var sabojāt citus nesaistītus datus un, iespējams, to izmantos, lai jūsu tālrunis palaistu noteiktu kodu, kuru viņi kontrolē.

(Atsauce: OmniROM Gerrit)

5. [CVE-2015-3827]

Diezgan līdzīgi šiem pēdējiem. Mainīgais tiek izmantots, izlaižot kādu atmiņu, un to var padarīt negatīvu atņemšanas laikā (kā iepriekš). Tas radītu ļoti lielu "izlaišanas" garumu, pārpildot buferi, nodrošinot piekļuvi atmiņai, kurai nevajadzētu piekļūt.

(Atsauce: OmniROM Gerrit)

Ir arī daži (potenciāli) saistīti labojumi, kas, šķiet, ir iekļuvuši arī [Android] 5.1.

(Atsauce: OmniROM Gerrit)

Tādējādi tiek pievienotas pārbaudes, lai apturētu problēmas ar iepriekšējo drošības labojumu, lai pievienotu robežpārbaudes, kuras pašas var tikt pārpildītas. Programmā C skaitļi, kurus var attēlot kā parakstīto int, tiek saglabāti kā parakstītie int. Pretējā gadījumā darbības laikā tie paliek nemainīgi. Šajās pārbaudēs daži veseli skaitļi varēja būt parakstīti (nevis neparakstīti), kas vēlāk samazinātu to maksimālo vērtību un ļautu notikt pārpildei.

(Atsauce: OmniROM Gerrit)

Vēl daži veseli skaitļi (kur skaitļi ir pārāk mazi, un pēc tam tiek veikta šo skaitļu atņemšana, ļaujot tiem kļūt negatīviem). Tas atkal rada lielu skaitu, nevis mazu, un tas rada tādas pašas problēmas kā iepriekš.

(Atsauce: OmniROM Gerrit)

Un visbeidzot vēl viena vesela skaitļa pārpilde. Tāpat kā iepriekš, to gatavojas izmantot citur, un tas var pārplūst.

(Atsauce: OmniROM Gerrit)"

Cik nopietna ir Stagefright?

Saskaņā ar emuāra ieraksts ko publicējis mātesuzņēmums, kas veic pētījumus Zimperium Research Labs, Stagefright izmantošana potenciāli atklāj 95% Android ierīču — aptuveni 950 miljoni — šī ievainojamība, jo tā ietekmē ierīces, kurās darbojas operētājsistēma Android 2.2 un uz augšu. Lai padarītu situāciju vēl ļaunāku, ierīces, kas jaunākas par Jelly Bean 4.3, ir pakļautas “sliktākajam riskam”, jo tajās nav iekļauti atbilstoši pasākumi pret šo izmantošanu.

Attiecībā uz kaitējumu, ko Stagefright varētu nodarīt, pulser_g2 atzīmēja:

[blockquote author="pulser_g2"]"Pati par sevi Stagefright nodrošinātu piekļuvi sistēmas lietotājam pa tālruni. Lai to ļaunprātīgi izmantotu, jums vajadzētu apiet ASLR (adreses telpas izkārtojuma nejaušību). Neatkarīgi no tā, vai tas ir sasniegts, šobrīd nav zināms. Šī izmantošana ļauj jūsu ierīcē palaist "patvaļīgu kodu" kā sistēmas vai multivides lietotājam. Tiem ir piekļuve ierīces audio un kamerai, un sistēmas lietotājs ir lieliska vieta, kur palaist saknes izmantošanu. Vai atceraties visus apbrīnojamos saknes izlietojumus, kurus izmantojāt, lai sakņotu tālruni?

Tos, iespējams, var klusi izmantot, lai jūsu ierīcē iegūtu saknes! Tam, kuram ir root, pieder tālrunis. Viņiem vajadzētu apiet SELinux, taču TowelRoot tas izdevās, un arī PingPong ir spējis. Tiklīdz viņi ir ieguvuši root tiesības, viņiem ir atvērts viss jūsu tālrunī. Ziņojumi, atslēgas utt."[/blockquote]Runājot par sliktākajiem scenārijiem, ir nepieciešama tikai MMS, lai piegādātu kodu un aktivizētu šo izmantošanu. Lietotājs pat nav jāatver ziņa jo daudzas ziņojumapmaiņas lietotnes iepriekš apstrādā MMS, pirms lietotājs ar tām mijiedarbojas. Tas atšķiras no pikšķerēšanas uzbrukumiem, jo ​​lietotājs var pilnībā nepamanīt veiksmīgu uzbrukumu, tādējādi apdraudot visus pašreizējos un turpmākos datus tālrunī.

Ar ko Stagefright atšķiras no citām “masveida ievainojamībām”?

"Visas ievainojamības rada zināmu risku lietotājiem. Šis ir īpaši riskants, jo, ja kāds atrod veidu, kā tai uzbrukt attālināti (tas ir iespējams, ja tiek atrasts veids, kā apiet ASLR), tas var tikt aktivizēts, pirms jūs pat saprotat, ka esat zem uzbrukums"

Vecākiem ekspluatācijas gadījumiem, piemēram, Android Installer nolaupīšana, FakeID, kā arī saknes izmantošanai, piemēram, TowelRoot un PingPong, ir nepieciešama lietotāja mijiedarbība, lai tos izpildītu. Lai gan tie joprojām ir “ekspluatācija” apstāklī, ka, ja tos izmanto ļaunprātīgi, var tikt nodarīts liels kaitējums, fakts paliek fakts, ka Stagefright teorētiski ir nepieciešams tikai upura mobilā tālruņa numurs, lai pārvērstu viņa tālruni par Trojas zirgu, un tāpēc pēdējā laikā tam tiek pievērsta tik liela uzmanība dienas.

Tomēr Android nav pilnībā pakļauts šīs izmantošanas žēlastībai. Android drošības vadošais inženieris Adrians Ludvigs pievērsās dažām problēmām a Google+ ziņa:

[blockquote author="Adrian Ludwig"]"Ir izplatīts, kļūdains pieņēmums, ka jebkuru programmatūras kļūdu var pārvērst par drošības ļaunprātīgu izmantošanu. Patiesībā lielākā daļa kļūdu nav izmantojamas, un Android ir daudz darījis, lai uzlabotu šīs izredzes...

Ir saraksts ar dažām tehnoloģijām, kas ieviestas kopš Ice Cream Sandwich (Android 4.0). šeit. Vispazīstamākais no tiem ir Address Space Layout Randomization (ASLR), kas tika pilnībā pabeigts operētājsistēmā Android 4.1 ar atbalstu PIE (no pozīcijas neatkarīgi izpildāmie faili), un tagad tas ir pieejams vairāk nekā 85% Android ierīces. Šī tehnoloģija apgrūtina uzbrucēja iespējas uzminēt koda atrašanās vietu, kas ir nepieciešama veiksmīgas ekspluatācijas izveidei...

Mēs neapstājāmies ar ASLR, esam pievienojuši arī NX, FortifySource, Read-Only-Relocations, Stack Canaries un daudz ko citu."[/blockquote]

Tomēr joprojām nevar noliegt, ka Stagefright ir nopietns jautājums Android nākotnei, un tāpēc iesaistītās puses to uztver nopietni. Stagefright uzsvēra arī baltos ziloņus telpā — sadrumstalotības problēmu un to, ka atjauninājumi beidzot sasniedz patērētāju.

Atjaunināšanas dilemma

Runājot par atjauninājumiem, ir patīkami redzēt, ka oriģinālo iekārtu ražotāji uzņemas atbildību par lietotāju drošību, kā daudzi ir solījuši uzlabot atjaunināšanas procesu, īpaši, lai iekļautu drošības labojumus un ielāpus tādiem ekspluatācijas veidiem kā Stagefright.

Viens no pirmajiem, kas izlaida oficiālu paziņojumu, ir solījis Google ikmēneša drošības atjauninājumi (papildus plānotajiem OS un platformas atjauninājumiem) lielākajai daļai tās Nexus ierīču, tostarp gandrīz 3 gadus vecajam Nexus 4. Samsung arī sekoja šim piemēram, paziņojot, ka sadarbosies ar pārvadātājiem un partneriem, lai ieviestu a ikmēneša drošības atjaunināšanas programma taču tajā neizdevās norādīt šīs ieviešanas ierīces un laika grafiku. Tas ir interesanti, jo tajā ir minēta "ātrā pieeja" drošības atjauninājumiem sadarbībā ar mobilo sakaru operatoriem, lai mēs varētu sagaidiet biežākus atjauninājumus (lai gan balstīti uz drošību, bet cerams, ka tas arī paātrinās programmaparatūras jaunināšanu) pārvadātājam ierīces.

Citi oriģinālo iekārtu ražotāji, kas pievienosies komplektam, ietver LG, kas pievienosies ikmēneša drošības atjauninājumi. Motorola arī ir paziņojusi to ierīču saraksts, kuras tiks atjauninātas ar Stagefright labojumiem, un sarakstā ir iekļautas gandrīz visas ierīces, ko uzņēmums ražojis kopš 2013. gada. To ir teicis arī Sony tās ierīces drīz saņems ielāpus arī.

Reiz arī mobilo sakaru operatori gaida atjauninājumus. Sprintam ir izdeva paziņojumu ka dažas ierīces jau ir saņēmušas Stagefright ielāpu, un atjauninājumam ir ieplānots vairāk ierīču. AT&T arī sekoja šim piemēram izdodot ielāpu dažām ierīcēm. Verizon ir izdevusi arī ielāpus, lai gan šī ir lēna izlaišana, kas dod priekšroku augstākās klases viedtālruņiem, piemēram, Galaxy S6 Edge un Note 4. T-Mobile Note 4 saņēma arī Stagefright ielāpu atjauninājumu.

Ja esat tiešais lietotājs, varat veikt dažus piesardzības pasākumus, lai samazinātu iespēju tikt uzbrukumam. Vispirms atspējojiet MMS ziņu automātisko izgūšanu tālrunī esošajās ziņojumapmaiņas lietotnēs. Tam vajadzētu kontrolēt gadījumus, kad nav nepieciešama lietotāja mijiedarbība, lai ekspluatācija darbotos. Pēc tam izvairieties no multivides lejupielādes no MMS ziņām no nezināmiem un neuzticamiem avotiem.

Kā XDA jaudas lietotājs jūs arī varat rediģējiet būvēšanas rekvizītu, lai atspējotu Stagefright. Šis nav pilnīgs un drošs veids, kā izglābties no Stagefright, taču varat izmantot savas iespējas, lai samazinātu veiksmīga uzbrukuma iespējamību, ja esat iestrēdzis ar vecāku Android versiju. Ir arī pielāgoti ROM risinājumi, no kuriem lielākā daļa regulāri sinhronizē avotus ar AOSP, un tādējādi tajos būs iekļauti Stagefright labojumi. Ja izmantojat AOSP balstītu ROM, ir ļoti ieteicams atjaunināt uz jaunāku ROM versiju, kurā ir iekļauti Stagefright ielāpi. Tu vari izmantot šī lietotne lai pārbaudītu, vai Stagefright ietekmē jūsu pašreizējo ikdienas vadītāju.

Android, Post-Stagefright

Stagefright ir bijis tikai modinātājs Android un tās sadrumstalotības problēmai, kā arī atjauninājumiem. Tas parāda, kā nav skaidra mehānisma, ar kura palīdzību šādus kritiskus labojumus var savlaicīgi ieviest daudzās ierīcēs. Kamēr oriģinālo iekārtu ražotāji mēģina ieviest ielāpus ierīcēm, skarbā patiesība ir tāda, ka lielākā daļa šo labojumu attieksies tikai uz jaunākajiem vadošajiem modeļiem. Citas ierīces, kas nav vadošās un vecākas ierīces, vēl mazāk no mazākiem oriģinālo iekārtu ražotājiem, turpinās saskarties ar līdzīgām Stagefright ierīcēm.

Šim varoņdarbam ir sudraba odere: Tas atkārtoti pievērsa uzmanību Android atjaunināšanas procesam un izvirzīja to tādā gaismā, kas nepiesaistīs tik daudz nākotnes korporatīvo uzņēmumu, lai Android lietotu uzņēmuma vajadzībām. Tā kā Google strādā pie lielākas uzņēmumu ieviešanas, tas būs spiests pārdomāt savu atjaunināšanas stratēģiju un kontroles apjomu, ko tā nodrošina OEM.

Tā kā Android M ar katru dienu tuvojas izlaišanai tirgū, nebūtu nekāds pārsteigums, ja Google izvēlētos atdalīt arvien vairāk AOSP komponentu par labu Play pakalpojumu pakotnei. Galu galā šī ir viena joma, ko Google joprojām pilnībā kontrolē, ja ierīce tiks piegādāta kopā ar Google Play veikalu. Šis ir savi mīnusi atklātā avota zonu aizstāšanas veidā ar tuvu avota sienām.

Spekulējot par Android nākotni, pastāv (ļoti maza) iespēja, ka Google var arī ierobežot izmaiņas, ko OEM var veikt AOSP. Ar RRO ietvars Tā kā operētājsistēmā Android M darbojas funkcionālā stāvoklī, Google varētu ierobežot OEM, lai veiktu tikai kosmētiskas izmaiņas RRO apvalku veidā. Tam vajadzētu nodrošināt ātrāku atjauninājumu izvietošanu, taču tas būtu saistīts ar to, ka OEM tiek liegta iespēja pilnībā pielāgot Android.

Vēl viens veids, kas varētu būt iespējams, būtu noteikt to obligātu visām ierīcēm, ar kurām tiek piegādāts Google Play veikalā, lai saņemtu garantētus drošības atjauninājumus uz noteiktu laika periodu, iespējams, diviem gadiem. Play pakalpojumu ietvaru var izmantot, lai pārbaudītu svarīgu drošības atjauninājumu un ielāpu esamību, un neatbilstības gadījumā piekļuve Play veikalam tiek anulēta.

Noslēguma piezīmes

Labākajā gadījumā tās joprojām ir spekulācijas, jo nav eleganta veida, kā atrisināt šo problēmu. Ja neņem vērā ļoti totalitāru pieeju, labojumu sasniedzamībā vienmēr būs kādi trūkumi. Ņemot vērā Android ierīču lielo skaitu, katras ierīces drošības statusa izsekošana būtu ļoti milzīgs uzdevums. Stundas nepieciešamība ir Android atjaunināšanas veida pārdomāšana, jo pašreizējais veids noteikti nav labākais. Mēs, XDA izstrādātāji, ceram, ka Android joprojām paliek uzticīgs savām atvērtā pirmkoda saknēm, vienlaikus strādājot kopā ar Google slēgtā pirmkoda plāniem.

Vai jūsu tālrunis ir neaizsargāts pret Stagefright? Vai jūs domājat, ka jūsu tālrunis kādreiz saņems Stagefright ielāpu? Paziņojiet mums zemāk esošajos komentāros!