Stagefright: Izkoriščanje, ki je spremenilo Android

Ena najmočnejših točk Androida je predvsem njegova odprtokodna narava, ki zainteresiranim stranem omogoča, da razcepijo, spremenijo in redistribuirajo OS na način, ki ustreza njihovim posebnim potrebam. Toda prav ta prednost odprtokodnosti deluje kot dvorezen meč, ko gre za vprašanja zlonamerne programske opreme in varnosti. Lažje je najti in popraviti napake, če imate veliko sposobnih sodelavcev pri projektu, katerega izvorna koda je prosto dostopna. Vendar pa odpravljanje težave na ravni vira pogosto ne pomeni, da je težava odpravljena v rokah končnega potrošnika. Kot tak Android ni najboljša izbira, ko gre za izbiro operacijskega sistema za potrebe podjetij, občutljivih na podatke.

Na Google I/O 2014 je Google dal svoj prvi zagon k bolj varnemu in podjetjem prijaznemu ekosistemu z uvedbo Program Android For Work. Android For Work je sprejel pristop dvojnega profila za potrebe podjetij, pri čemer lahko skrbniki IT ustvarijo ločeni uporabniški profili za zaposlene – eden je osredotočen na delo, ostali pa puščajo osebne profile zaposlenih uporaba. Z uporabo šifriranja na podlagi strojne opreme in pravilnikov, ki jih upravlja skrbnik, so delovni in osebni podatki ostali ločeni in varni. Nato je Android For Work v poznejših mesecih prejel več pozornosti, pri čemer je bil velik poudarek na varnosti naprave pred zlonamerno programsko opremo. Načrtoval je tudi Google

omogočite popolno šifriranje naprave za vse naprave ki naj bi bili izdani z Androidom Lollipop takoj po pripravi, vendar je bilo to opuščeno zaradi težav z zmogljivostjo, pri čemer je bila poteza izbirna za proizvajalce originalne opreme.

Prizadevanje za varen Android ni povsem Googlovo delo, saj je Samsung pri tem odigral precej pomembno vlogo prek svojih KNOX prispevki k AOSP, ki navsezadnje okrepljen Android For Work. Vendar pa nedavna varnostna zloraba in ranljivosti v Androidu kažejo na težko nalogo, ko gre za priljubljenost za sprejemanje v podjetjih. Primer je nedavna ranljivost Stagefright.

Vsebina:

• Kaj je Stagefright?
• Kako resen je Stagefright?
• V čem se Stagefright razlikuje od drugih "ogromnih ranljivosti"?
• Dilema posodobitve
• Android, Post-Stagefright
• Zaključne opombe

Kaj je Stagefright?

Preprosto povedano, Stagefright je izkoriščanje, ki uporablja knjižnico kod za predvajanje medijev v sistemu Android, imenovano libstagefright. Mehanizem libstagefright se uporablja za izvajanje kode, ki je prejeta v obliki zlonamernega videa prek MMS-a, zato je za izvedbo uspešnega napada potrebna samo mobilna številka žrtve.

Obrnili smo se na našega internega strokovnjaka, višjega priznanega razvijalca XDA in skrbnika razvijalca pulser_g2 za podrobnejšo razlago.

"Ko to pišem, je bilo treba [Stagefright] izkoriščanje pojasniti pri BlackHatu [Povezava], čeprav še ni na voljo nobenih diapozitivov ali podrobnosti o beli knjigi.

Zato to razlago podajam bolj kot grobo predstavo o tem, kaj se dogaja, ne pa kot zelo poglobljeno razlago s popolno natančnostjo itd.

Obstaja več različnih hroščev, ki sestavljajo Stagefright, in ti imajo svoj CVE [Pogoste ranljivosti in izpostavljenosti] številke za sledenje:

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

Na žalost popravki, ki so na voljo, niso neposredno povezani z vsakim CVE (kot bi morali biti), zato bo razlaga tega nekoliko nerodna.

1. [CVE-2015-1538]

V kodi za obravnavo MPEG4 so metapodatki 3GPP (stvari, ki opisujejo obliko in druge dodatne informacije, ko je videoposnetek v obliki zapisa 3GPP) napaka. Ni zavrnil metapodatkov, kjer so bili podatki pretirano veliki, temveč je le preveril, ali so premajhni. To je pomenilo, da je lahko napadalec ustvaril "spremenjeno" ali "poškodovano" datoteko, ki bi imela daljši del metapodatkov, kot bi moral.

Eden od velikih izzivov pri pisanju kode za obdelavo "nezaupljivih" podatkov (tj. od uporabnika ali s katerega koli drugega mesta zunaj vaše kode) je obravnavanje podatkov spremenljive dolžine. Videoposnetki so odličen primer tega. Programska oprema mora dinamično dodeliti pomnilnik, odvisno od tega, kaj se dogaja.

V tem primeru je vmesni pomnilnik ustvarjen kot kazalec na nek pomnilnik, vendar je bila dolžina matrike, na katero kaže, za en element prekratka. Metapodatki so bili nato prebrani v to matriko in bilo je mogoče, da zadnji vnos v tej matriki ni bil "null" (ali nič). Pomembno je, da je zadnji element v nizu nič, saj programska oprema tako sporoči, da je niz končan. Z možnostjo, da zadnja vrednost ni enaka nič (ker je bil niz potencialno za en element premajhen), bi zlonamerno kodo lahko prebral drug del kode in prebral preveč podatkov. Namesto da bi se ustavil na koncu te vrednosti, bi lahko nadaljeval z branjem drugih podatkov, ki jih ne bi smel brati.

(Ref: OmniROM Gerrit)

2. [CVE-2015-1539]

Najkrajša možna "velikost" metapodatkov naj bo 6 bajtov, ker gre za niz UTF-16. Koda vzame velikost celega števila in od nje odšteje 6. Če bi bila ta vrednost manjša od 6, bi se odštevanje "spodbudilo" in ovilo okoli, na koncu pa bi dobili zelo veliko število. Predstavljajte si, da lahko na primer štejete samo od 0 do 65535. Če vzamete številko 4 in odštejete 6, ne morete iti pod ničlo. Torej se vrneš na 65535 in šteješ od tam. To se tukaj dogaja!

Če je bila prejeta dolžina manjša od 6, bi lahko prišlo do nepravilnega dekodiranja okvirjev, saj byteswap proces uporablja spremenljivko len16, katere vrednost je pridobljena iz izračuna, ki se začne z (velikost-6). To bi lahko povzročilo veliko večjo operacijo zamenjave, kot je bilo predvideno, kar bi nepričakovano spremenilo vrednosti v podatkih okvirja.

(Ref: OmniROM Gerrit)

3. [CVE-2015-3824]

Velika stvar! Ta je grd. Obstaja ravno nasprotje te zadnje težave - celoštevilsko prelivanje, kjer lahko celo število postane "preveliko". Če dosežete 65535 (na primer) in ne morete več šteti, bi se zavrteli in šli na 0 naprej!

Če pomnilnik dodeljujete na podlagi tega (kar počne Stagefright!), bi imeli v nizu veliko premalo pomnilnika. Ko bi bili podatki vneseni v to, bi potencialno prepisali nepovezane podatke s podatki, ki jih nadzoruje ustvarjalec zlonamerne datoteke.

(Ref: OmniROM Gerrit)

4. [CVE-2015-3826]

Še en grd! Zelo podoben zadnjemu - še en celoštevilski preliv, kjer bi bilo polje (uporabljeno kot medpomnilnik) premajhno. To bi omogočilo prepis nepovezanega pomnilnika, kar je spet slabo. Nekdo, ki lahko zapisuje podatke v pomnilnik, lahko poškoduje druge podatke, ki niso povezani, in to potencialno uporabi za izvajanje neke kode, ki jo nadzoruje, v vašem telefonu.

(Ref: OmniROM Gerrit)

5. [CVE-2015-3827]

Precej podobno tem zadnjim. Spremenljivka se uporabi pri preskoku nekega pomnilnika in ta lahko med odštevanjem postane negativen (kot zgoraj). To bi povzročilo zelo veliko dolžino "preskoka", prepolnjevanje medpomnilnika, kar bi omogočilo dostop do pomnilnika, do katerega ne bi smeli dostopati.

(Ref: OmniROM Gerrit)

Obstaja tudi nekaj (potencialno) povezanih popravkov, za katere se zdi, da so prav tako prišli v [Android] 5.1.

(Ref: OmniROM Gerrit)

To dodaja preverjanja za zaustavitev težav s preteklim varnostnim popravkom za dodajanje preverjanj meja, ki se lahko presežejo. V C so števila, ki jih je mogoče predstaviti kot signed int, shranjena kot signed int. Sicer med delovanjem ostanejo nespremenjeni. Pri teh preverjanjih bi lahko bila nekatera cela števila predpisana (namesto nepredznačena), kar bi pozneje zmanjšalo njihovo največjo vrednost in omogočilo prelivanje.

(Ref: OmniROM Gerrit)

Nekaj ​​več celih podtokov (kjer so številke prenizke, nato pa se na teh številkah izvede odštevanje, kar jim omogoči, da postanejo negativne). To spet vodi do velikega števila namesto majhnega, kar povzroča enake težave kot zgoraj.

(Ref: OmniROM Gerrit)

In končno, še en celoštevilski preliv. Enako kot prej, kmalu ga bodo uporabili drugje in lahko se prelije.

(Ref: OmniROM Gerrit)"

Kako resen je Stagefright?

Glede na blog objava ki ga je objavilo matično raziskovalno podjetje Zimperium Research Labs, izkoriščanje Stagefright potencialno razkriva 95 % naprav Android – približno 950 milijonov – je izpostavljeno tej ranljivosti, saj vpliva na naprave s sistemom Android 2.2 in gor. Da bi bile stvari še hujše, so naprave pred Jelly Bean 4.3 izpostavljene »najhujšemu tveganju«, saj ne vsebujejo ustreznih ublažitev tega izkoriščanja.

V zvezi s škodo, ki bi jo lahko povzročil Stagefright, je pulser_g2 pripomnil:

[blockquote author="pulser_g2"]"Sam po sebi bi Stagefright omogočil dostop uporabniku sistema na telefonu. Vendar bi morali zaobiti ASLR (randomizacija postavitve naslovnega prostora), da bi ga dejansko zlorabili. Trenutno ni znano, ali je bilo to doseženo ali ne. Ta izkoriščanje omogoča zagon "poljubne kode" v vaši napravi kot uporabnik sistema ali medija. Ti imajo dostop do zvoka in kamere v napravi, uporabnik sistema pa je odličen kraj za zagon korenskega izkoriščanja. Se spomnite vseh neverjetnih root podvigov, ki ste jih uporabili za rootanje telefona?

Ti bi se lahko potencialno tiho uporabili za pridobivanje root-ja v vaši napravi! Kdor ima root, ima telefon. Morali bi zaobiti SELinux, vendar je to uspelo TowelRootu in tudi PingPongu. Ko pridobijo root, jim je odprto vse na vašem telefonu. Sporočila, ključi itd."[/blockquote]Če govorimo o najslabšem možnem scenariju, je za dostavo kode in sprožitev tega izkoriščanja potreben samo MMS. Uporabnik sploh ni treba odpreti sporočila saj veliko aplikacij za sporočanje MMS vnaprej obdela, preden uporabnik z njim komunicira. To se razlikuje od napadov s lažnim predstavljanjem, saj lahko uporabnik popolnoma pozabi na uspešen napad, ki ogroža vse sedanje in prihodnje podatke v telefonu.

V čem se Stagefright razlikuje od drugih "ogromnih ranljivosti"?

»Vse ranljivosti predstavljajo določeno tveganje za uporabnike. Ta je še posebej tvegan, saj če nekdo najde način, da ga napade na daljavo (kar je možno, če je bila najdena pot zaobiti ASLR), se lahko sproži, preden se sploh zaveš, da si pod napad"

Starejša izkoriščanja, kot je ugrabitev namestitvenega programa Android, FakeID, kot tudi korenska izkoriščanja, kot sta TowelRoot in PingPong, zahtevajo interakcijo uporabnika na neki točki, da se lahko izvedejo. Medtem ko so še vedno "izkoriščanja" v dejstvu, da lahko povzroči veliko škode, če se uporabljajo zlonamerno, ostaja dejstvo, da Stagefright teoretično potrebuje samo mobilno številko žrtve, da spremeni telefon v trojanca, zato se temu v zadnjem času posveča toliko pozornosti dnevi.

Vendar Android ni povsem prepuščen na milost in nemilost tega izkoriščanja. Vodilni inženir za varnost Android, Adrian Ludwig, je obravnaval nekatere pomisleke v a objava v storitvi Google+:

[blockquote author="Adrian Ludwig"]"Obstaja pogosta, zmotna domneva, da je mogoče vsako napako programske opreme spremeniti v varnostno izkoriščanje. Pravzaprav večine hroščev ni mogoče izkoristiti in Android je naredil veliko stvari, da bi izboljšal te možnosti ...

Naveden je seznam nekaterih teh tehnologij, ki so bile uvedene od Ice Cream Sandwicha (Android 4.0). tukaj. Najbolj znana med njimi se imenuje randomizacija postavitve naslovnega prostora (ASLR), ki je bila v celoti dokončana. v sistemu Android 4.1 s podporo za PIE (position Independent Executables) in je zdaj v več kot 85 % sistema Android naprave. Ta tehnologija napadalcu oteži uganiti lokacijo kode, ki je potrebna za uspešno izkoriščanje ...

Nismo se ustavili pri ASLR, dodali smo tudi NX, FortifySource, Read-Only-Relocations, Stack Canaries in še več."[/blockquote]

Vendar pa še vedno ni mogoče zanikati, da je Stagefright resna zadeva za prihodnost Androida in jo kot tako vpletene zainteresirane strani jemljejo resno. Stagefright je izpostavil tudi bele slone v prostoru – problem razdrobljenosti in posodobitev, ki končno dosežejo potrošnika.

Dilema posodobitve

Ko že govorimo o posodobitvah, je dobro videti, da proizvajalci originalne opreme prevzemajo odgovornost za varnost uporabnikov, kot so mnogi obljubili, izboljšajte postopek posodabljanja posebej za vključevanje varnostnih popravkov in popravkov za podvige, kot je Stagefright.

Google je obljubil, da bo med prvimi objavil uradno izjavo mesečne varnostne posodobitve (poleg načrtovanih posodobitev OS in platforme) za večino svojih naprav Nexus, vključno s skoraj 3 leta starim Nexusom 4. Temu je sledil tudi Samsung z napovedjo, da bo sodeloval z operaterji in partnerji pri izvajanju a program mesečne varnostne posodobitve vendar ni uspelo določiti naprav in podrobnosti o časovnici te izvedbe. To je zanimivo, saj omenja "hitri" pristop k varnostnim posodobitvam v sodelovanju z operaterji, tako da lahko pričakujte pogostejše posodobitve (čeprav temeljijo na varnosti, vendar upajmo, da bodo pospešile tudi nadgradnje vdelane programske opreme) pri operaterju naprave.

Drugi OEM-ji, ki se pridružujejo paketu, vključujejo LG, ki se bo pridružil mesečne varnostne posodobitve. Motorola je prav tako napovedala seznam naprav, ki bodo posodobljene s popravki Stagefright, seznam pa vključuje skoraj vse naprave, ki jih je podjetje izdelalo od leta 2013. To je povedal tudi Sony njegove naprave bodo kmalu prejele popravke preveč.

Za enkrat tudi operaterji prihajajo s posodobitvami. Sprint ima izdal izjavo da so nekatere naprave že prejele popravek Stagefright, pri čemer je predvidena posodobitev za več naprav. AT&T je prav tako sledil z izdajo popravka za nekatere naprave. Verizon je izdal tudi popravke, čeprav gre za počasno uvajanje, ki daje prednost pametnim telefonom višjega cenovnega razreda, kot sta Galaxy S6 Edge in Note 4. T-Mobile Note 4 je prejel tudi posodobitev popravka Stagefright.

Kot končni uporabnik obstaja nekaj previdnostnih korakov, ki lahko zmanjšajo vaše možnosti za napad. Za začetek onemogočite samodejno pridobivanje sporočil MMS v aplikacijah za sporočanje v telefonu. To bi moralo nadzorovati primere, ko za delovanje izkoriščanja ni bila potrebna nobena interakcija uporabnika. Po tem pazite, da se izognete prenašanju medijev iz sporočil MMS iz neznanih in nezaupljivih virov.

Kot napredni uporabnik XDA lahko tudi vi uredite svoj gradbeni element, da onemogočite Stagefright. To ni popoln in zanesljiv način, da se rešite pred Stagefrightom, vendar lahko izkoristite svoje možnosti in zmanjšate verjetnost uspešnega napada, če ste obtičali na starejši različici Androida. Obstajajo tudi rešitve ROM po meri, od katerih večina redno sinhronizira vire z AOSP in bodo zato v njih vključeni popravki Stagefright. Če uporabljate ROM, ki temelji na AOSP, je zelo priporočljivo, da posodobite na novejšo izdajo ROM-a, ki vključuje popravke Stagefright. Lahko uporabiš ta aplikacija da preverite, ali Stagefright vpliva na vaš trenutni dnevni voznik.

Android, Post-Stagefright

Stagefright ni bil nič drugega kot opozorilo na Android in njegov problem razdrobljenosti ter posodobitev. Poudarja, da ni jasnega mehanizma, s katerim bi lahko takšne kritične popravke pravočasno uvedli v številne naprave. Medtem ko proizvajalci originalne opreme poskušajo uvesti popravke za naprave, je huda resnica ta, da bo večina teh popravkov omejena samo na nedavne vodilne naprave. Druge ne-vodilne in starejše naprave, še manj manjših proizvajalcev originalne opreme, bodo še naprej izpostavljene Stagefrightu.

Ta podvig je srebrna podloga: Ponovno je pritegnil pozornost na postopek posodabljanja Androida in ga predstavil v luči, ki ne bo pritegnila toliko prihodnjih podjetij k prevzemu Androida za poslovno uporabo. Ker si Google prizadeva za večjo sprejetost v podjetjih, bo prisiljen ponovno razmisliti o svoji strategiji posodabljanja in obsegu nadzora, ki ga omogoča proizvajalcem originalne opreme.

Ker se Android M iz dneva v dan bližje izdaji na trgu, ne bi bilo presenečenje, če bi se Google odločil ločiti vse več komponent AOSP v korist svojega paketa storitev Play. Konec koncev je to področje, nad katerim ima Google še vedno popoln nadzor, če bo naprava dobavljena s trgovino Google Play. to ima svoje slabosti v obliki zamenjave odprtokodnih območij z zaprtokodnimi zidovi.

Ko špekuliramo o prihodnosti Androida, obstaja (zelo majhna) možnost, da lahko Google tudi omeji spremembe, ki jih proizvajalci originalne opreme lahko naredijo za AOSP. z okvir RRO Ker je prisoten v funkcionalnem stanju v sistemu Android M, bi lahko Google proizvajalce originalne opreme omejil na samo kozmetične spremembe v obliki preoblek RRO. To bi moralo omogočiti hitrejšo uvedbo posodobitev, vendar bi bilo za ceno proizvajalcem originalne opreme onemogočeno možnost popolne prilagoditve Androida.

Druga pot, ki bi lahko bila možnost, bi bila, da postane obvezna za vse naprave, s katerimi se pošilja Trgovina Google Play bo prejemala zajamčene varnostne posodobitve za določeno časovno obdobje, po možnosti dve leta. Ogrodje storitev Play bi lahko uporabili za preverjanje prisotnosti pomembnih varnostnih posodobitev in popravkov, pri čemer bi bil v primeru neskladnosti dostop do Trgovine Play preklican.

Zaključne opombe

To so v najboljšem primeru še vedno ugibanja, saj ni elegantnega načina za odpravo te težave. Razen zelo totalitarnega pristopa bo vedno nekaj pomanjkljivosti v dosegu popravkov. Zaradi velikega števila naprav Android bi bilo sledenje statusu varnosti vsake naprave zelo ogromna naloga. Potreba po ponovnem razmisleku o načinu posodabljanja Androida, saj trenutni način zagotovo ni najboljši. Pri XDA Developers upamo, da bo Android še vedno ostal zvest svojim odprtokodnim koreninam, hkrati pa bo sodeloval z Googlovimi zaprtokodnimi načrti.

Je vaš telefon ranljiv za Stagefright? Ali menite, da bo vaš telefon kdaj prejel popravek Stagefright? Sporočite nam v komentarjih spodaj!