Stagefright on üks halvimaid kasutusviise, mida Android on viimasel ajal näinud. Klõpsake üksikasjade kohta lisateabe saamiseks ja teadmiseks, kuidas ennast kaitsta!
Androidi üks tugevamaid külgi on olnud eelkõige selle avatud lähtekoodiga olemus, mis võimaldab sidusrühmadel OS-i hargida, muuta ja ümber levitada viisil, mis vastab nende konkreetsetele vajadustele. Kuid see avatud lähtekoodiga olemise eelis toimib pahavara ja turvalisuse küsimustes nagu kahe teraga mõõk. Vigu on lihtsam leida ja parandada, kui projektis on palju võimekaid kaastöölisi, mille lähtekood on vabalt saadaval. Probleemi lahendamine allika tasandil ei tähenda aga sageli seda, et probleem lahendatakse lõpptarbija käes. Sellisena ei ole Android andmetundlike ettevõtte vajaduste jaoks operatsioonisüsteemi valimisel parim valik.
Google I/O 2014. aastal andis Google oma esimese tõuke turvalisema ja ettevõttesõbralikuma ökosüsteemi suunas, käivitades Android for Work programm. Android For Work võttis ettevõtte vajaduste jaoks kasutusele kaksikprofiili lähenemisviisi, mille abil IT-administraatorid said luua a erinevad kasutajaprofiilid töötajatele – üks keskendub tööle, jättes teised profiilid töötajate isiklikuks kasutamiseks kasutada. Riistvarapõhise krüptimise ja administraatori poolt hallatavate poliitikate kasutamise tõttu jäid töö- ja isikuandmed eristatuks ja turvaliseks. Seejärel pöörati Android For Workile viimastel kuudel rohkem tähelepanu, kusjuures suurt tähelepanu pöörati seadme turvalisusele pahavara vastu. Ka Google plaanis
Surve turvalise Androidi poole ei ole täielikult Google'i töö, kuna Samsung on oma kaudu mänginud selles üsna olulist rolli KNOX panustab AOSP-sse, mis lõpuks tugevdatud Android For Work. Kuid hiljutised Androidi turbekasutused ja haavatavused osutavad ettevõttes kasutuselevõtu populaarsuse tõusule. Näide on hiljutine Stagefrighti haavatavus.
Sisu:
- Mis on Stagefright?
- Kui tõsine on Stagefright?
- Mille poolest erineb Stagefright teistest "massiivsetest haavatavustest"?
- Värskendusdilemma
- Android, Post-Stagefright
- Lõppmärkused
Mis on Stagefright?
Lihtsamalt öeldes on Stagefright ärakasutamine, mis kasutab Androidis meediumi taasesitamiseks kooditeegi nimega libstagefright. Libstagefrighti mootorit kasutatakse MMS-i kaudu pahatahtliku video kujul vastuvõetud koodi käivitamiseks, mistõttu on edukaks rünnakuks vaja ainult ohvri mobiilinumbrit.
Võtsime ühendust meie ettevõttesisese eksperdi, XDA tunnustatud vanemarendaja ja arendajaadministraatoriga pulser_g2 üksikasjalikuma selgituse andmiseks.
"Kui ma seda kirjutan, pidi [Stagefrighti] ärakasutamist selgitama BlackHat [Link], kuigi slaidid või valge paberi üksikasjad pole veel saadaval.
Seetõttu annan selle selgituse pigem umbkaudse ettekujutusena sellest, mis toimub, mitte väga põhjaliku ja täie täpsusega selgitusena jne.
Stagefright koosneb mitmest erinevast veast ja neil on oma CVE [Levinud haavatavused ja kokkupuuted] numbrid jälgimiseks:
- CVE-2015-1538
- CVE-2015-1539
- CVE-2015-3824
- CVE-2015-3826
- CVE-2015-3827
- CVE-2015-3828
- CVE-2015-3829
Kahjuks ei ole saadaolevad plaastrid otse iga CVE-ga seotud (nagu nad peaksid olema), nii et seda on veidi segane selgitada.
1. [CVE-2015-1538]
MPEG4 käsitluskoodis on 3GPP metaandmete (vormingut ja muud lisateavet kirjeldavad asjad, kui video on 3GPP-vormingus) töötlemiskood vigane. See ei lükanud tagasi metaandmeid, kus andmed olid liiga suured, vaid kontrollis ainult, kas need olid liiga väikesed. See tähendas, et ründajal oli võimalik luua "muudetud" või "rikutud" fail, millel oleks pikem metaandmete osa, kui peaks.
Üks suuremaid väljakutseid koodi kirjutamisel "mitteusaldusväärsete" andmete (st kasutajalt või mis tahes muust koodivälisest kohast) käsitlemisel on muutuva pikkusega andmete töötlemine. Videod on selle suurepärane näide. Tarkvara peab mälu dünaamiliselt eraldama, olenevalt sellest, mis toimub.
Sel juhul luuakse puhver, mis osutab mõnele mälule, kuid massiivi pikkus, millele see osutab, oli ühe elemendi võrra liiga lühike. Seejärel loeti metaandmed sellesse massiivi ja oli võimalik, et selle massiivi viimane kirje ei oleks "null" (või null). On oluline, et massiivi viimane üksus oleks null, sest nii annab tarkvara teada, et massiiv on valmis. Kui suudetakse muuta viimane väärtus nullist erinevaks (kuna massiiv oli potentsiaalselt üks element liiga väike), võib pahatahtlikku koodi lugeda mõni teine koodiosa ja lugeda liiga palju andmeid. Selle asemel, et peatuda selle väärtuse lõpus, võib see jätkata lugemist muudesse andmetesse, mida ta ei peaks lugema.
(Viide: OmniROM Gerrit)
2. [CVE-2015-1539]
Metaandmete lühim võimalik "suurus" peaks olema 6 baiti, kuna tegemist on UTF-16 stringiga. Kood võtab täisarvu väärtuse suuruse ja lahutab sellest 6. Kui see väärtus oleks väiksem kui 6, voolaks lahutamine alla ja keerduks ümber ning tulemuseks oleks väga suur arv. Kujutage ette, kui saate näiteks lugeda ainult 0-st 65535-ni. Kui võtate arvu 4 ja lahutate 6, ei saa te alla nulli minna. Nii et lähete tagasi numbrile 65535 ja loendate sealt. See siin toimub!
Kui vastuvõetud pikkus on alla 6, võib see põhjustada kaadrite valesti dekodeerimise, kuna byteswap protsess kasutab muutujat len16, mille väärtus saadakse arvutusest, mis algab tähega (suurus-6). See võib põhjustada kavandatust palju suurema vahetusoperatsiooni, mis muudaks ootamatult kaadriandmete väärtusi.
(Viide: OmniROM Gerrit)
3. [CVE-2015-3824]
Suur tegija! See on vastik. Selle viimase probleemi täpne vastand on täisarvu ületäitumine, kus täisarv võib muutuda "liiga suureks". Kui jõuate (näiteks) 65535-ni ja ei suuda enam rohkem lugeda, veereksite ringi ja läheksite järgmiseks 0-ni!
Kui eraldate mälu selle põhjal (mida Stagefright teeb!), jääks massiivile eraldatud mälu liiga vähe. Kui andmed sellesse sisestati, kirjutaks see potentsiaalselt üle mitteseotud andmed andmetega, mida kontrollib pahatahtliku faili looja.
(Viide: OmniROM Gerrit)
4. [CVE-2015-3826]
Veel üks vastik! Väga sarnane eelmisele - veel üks täisarvu ületäitumine, kus massiiv (kasutatakse puhvrina) oleks liiga väike. See võimaldaks mitteseotud mälu üle kirjutada, mis on jällegi halb. Keegi, kes suudab andmeid mällu kirjutada, võib rikkuda muid mitteseotud andmeid ja võib kasutada seda oma juhitava koodi käivitamiseks teie telefonis.
(Viide: OmniROM Gerrit)
5. [CVE-2015-3827]
Üsna sarnane nendele viimastele. Muutujat kasutatakse mälu vahelejätmisel ja selle võib lahutamise ajal negatiivseks muuta (nagu ülalpool). Selle tulemuseks oleks väga suur "vahelejätmise" pikkus, mis täidaks puhvri, võimaldades juurdepääsu mälule, millele ei tohiks juurde pääseda.
(Viide: OmniROM Gerrit)
Samuti on mõned (potentsiaalselt) seotud parandused, mis näivad olevat jõudnud ka [Android] 5.1-sse.
(Viide: OmniROM Gerrit)
See lisab kontrollid, et peatada probleemid varasema turvaparandusega, et lisada piirikontrollid, mis võivad iseenesest üle ajada. C-s salvestatakse numbrid, mida saab esitada märgistatud int-idena. Vastasel juhul jäävad need toimingute ajal muutumatuks. Nendes kontrollides oleks võinud mõned täisarvud olla märgistatud (mitte märgita), mis vähendaks hiljem nende maksimaalset väärtust ja võimaldaks ülevoolu toimuda.
(Viide: OmniROM Gerrit)
Veel mõned täisarvude alavoolud (kus arvud on liiga väikesed ja seejärel tehakse nende arvude lahutamine, mis võimaldab neil minna negatiivseks). See toob jällegi kaasa suure arvu, mitte väikese arvu, ja see põhjustab samu probleeme, mis eespool.
(Viide: OmniROM Gerrit)
Ja lõpuks veel üks täisarvu ülevool. Sama, mis varem, hakatakse seda mujal kasutama ja see võib üle voolata.
(Viide: OmniROM Gerrit)"
Kui tõsine on Stagefright?
Vastavalt ajaveebi postitus Emauuringufirma Zimperium Research Labsi avaldatud Stagefrighti ärakasutamine võib potentsiaalselt paljastada 95% Android-seadmetest – ligikaudu 950 miljonit – on haavatavusega seotud, kuna see mõjutab seadmeid, milles töötab Android 2.2 ja üles. Asja teeb hullemaks see, et Jelly Bean 4.3-le eelnenud seadmed on „halvimas ohus”, kuna need ei sisalda selle ärakasutamise vastu piisavaid leevendusi.
Seoses kahjuga, mida Stagefright võib tekitada, märkis pulser_g2:
[blockquote author="pulser_g2"]"Iseenesest annaks Stagefright juurdepääsu süsteemikasutajale telefonis. Selle tegelikuks kuritarvitamiseks peaksite siiski ASLR-ist (aadressiruumi paigutuse randomiseerimisest) mööda minema. Kas see on saavutatud või mitte, pole praegu teada. See ärakasutamine võimaldab teie seadmes süsteemi- või meediumikasutajana käivitada "suvalise koodi". Neil on juurdepääs seadme helile ja kaamerale ning süsteemikasutaja on suurepärane koht juurkasutamise käivitamiseks. Kas mäletate kõiki hämmastavaid juurkasutusi, mida kasutasite oma telefoni juurutamiseks?
Neid saab potentsiaalselt vaikselt kasutada teie seadme juurutamiseks! See, kellel on root, omab telefoni. Nad peaksid SELinuxist mööda minema, kuid TowelRoot sai sellega hakkama ja ka PingPong on hakkama saanud. Kui nad juurduvad, on kõik teie telefonis neile avatud. Sõnumid, võtmed jne."[/blockquote]
Rääkides halvimatest stsenaariumidest, on koodi edastamiseks ja selle ärakasutamise käivitamiseks vaja ainult MMS-i. Kasutaja ei pea isegi sõnumit avama kuna paljud sõnumsiderakendused töötlevad MMS-i enne, kui kasutaja sellega suhtleb. See erineb andmepüügi rünnakutest, kuna kasutaja võib edukast rünnakust täiesti unustada, kahjustades kõiki telefonis olevaid ja tulevasi andmeid.
Mille poolest Stagefright erineb teistest "massiivsetest haavatavustest"?
"Kõik haavatavused kujutavad kasutajatele teatud ohtu. See on eriti riskantne, sest kui keegi leiab võimaluse seda eemalt rünnata (mis on võimalik, kui leitakse võimalus ASLR-ist kõrvale hiilida), võidakse see käivitada enne, kui saate arugi, et olete alla jäänud rünnak"
Vanemad ärakasutused, nagu Android Installeri kaaperdamine, FakeID, aga ka juurkasutusprogrammid, nagu TowelRoot ja PingPong, nõuavad teatud hetkel kasutaja sekkumist, et neid käivitada. Kuigi need on endiselt „ärakasutused”, kuna pahatahtlikul kasutamisel võib tekkida palju kahju, on tõsiasi, et Stagefright teoreetiliselt vajab ohver vaid mobiiltelefoni numbrit, et muuta oma telefon troojalaseks ja seetõttu pööratakse sellele viimasel ajal nii palju tähelepanu. päevadel.
Android ei ole siiski täielikult selle ärakasutamise meelevallas. Androidi turvalisuse juhtivinsener Adrian Ludwig käsitles mõningaid probleeme a Google+ postitus:
[blockquote author="Adrian Ludwig"]"On levinud, ekslik oletus, et iga tarkvaravea saab muuta turvalisuse ärakasutamiseks. Tegelikult pole enamikku vigu võimalik kasutada ja Android on nende tõenäosuste parandamiseks teinud palju asju...
Loetletud on mõned tehnoloogiad, mis on kasutusele võetud pärast Ice Cream Sandwichi (Android 4.0) siin. Tuntuim neist on nimetusega Address Space Layout Randomization (ASLR), mis sai täielikult valmis operatsioonisüsteemis Android 4.1, mis toetab PIE-d (Position Independent Executables) ja on nüüd enam kui 85% Androidist seadmeid. See tehnoloogia muudab ründaja jaoks keerulisemaks koodi asukoha äraarvamise, mida on vaja edukaks ärakasutamiseks...
Me ei piirdunud ASLR-iga, oleme lisanud ka NX, FortifySource, Read-Only-Relocations, Stack Canaries ja palju muud."[/blockquote]
Siiski ei saa endiselt eitada, et Stagefright on Androidi tuleviku jaoks tõsine asi ja seetõttu võtavad asjaosalised seda tõsiselt. Stagefright tõstis esile ka valged elevandid ruumis – killustatuse ja lõpuks tarbijani jõudvate uuenduste probleemi.
Värskendusdilemma
Värskendustest rääkides on hea tõdeda, et OEM-id võtavad kasutajate turvalisuse eest vastutuse, nagu paljud on lubanud täiustada värskendusprotsessi spetsiaalselt turvaparanduste ja paikade lisamiseks sellistele ärakasutajatele nagu Stagefright.
Google on lubanud esimeste seas, kes ametliku avalduse avaldas igakuised turvavärskendused (lisaks plaanitud operatsioonisüsteemi ja platvormi uuendustele) enamiku Nexuse seadmete jaoks, sealhulgas peaaegu 3 aastat vana Nexus 4 jaoks. Samsung on samuti järginud eeskuju, teatades, et teeb koostööd operaatorite ja partneritega, et rakendada a igakuine turvavärskendusprogramm kuid see ei suutnud selle rakenduse seadmeid ja ajaskaala üksikasju täpsustada. See on huvitav, kuna selles mainitakse koostöös operaatoritega turvavärskenduste kiiret lähenemist, et saaksime oodake operaatori sagedasemaid värskendusi (ehkki turbepõhiseid, kuid loodetavasti kiirendab see ka püsivara uuendamist) seadmeid.
Teised OEM-id, kes komplektiga liituvad, hõlmavad LG, kes ühineb igakuised turvavärskendused. Motorola on samuti teatanud uuendatavate seadmete loend Stagefrighti parandustega ja loend sisaldab peaaegu kõiki seadmeid, mida ettevõte on alates 2013. aastast valmistanud. Seda on öelnud ka Sony selle seadmed saavad varsti plaastrid ka.
Kord on ka operaatorid värskendustega tulemas. Sprintil on avaldas avalduse et mõned seadmed on juba saanud Stagefrighti plaastri ja värskenduse jaoks on plaanitud rohkem seadmeid. AT&T on samuti eeskuju järginud väljastades mõnele seadmele plaastri. Verizon on välja andnud ka plaastreid, ehkki see on aeglane levitamine, mis seab esikohale tipptasemel nutitelefonid, nagu Galaxy S6 Edge ja Note 4. T-Mobile Note 4 sai ka Stagefrighti plaastri värskenduse.
Lõppkasutajana on mõned ettevaatusabinõud, mida saab võtta, et vähendada teie võimalusi rünnata. Alustuseks keelake MMS-sõnumite automaatne allalaadimine oma telefonis olevates sõnumsiderakendustes. See peaks hoidma kontrolli all juhtumid, kus ärakasutamise toimimiseks ei olnud vaja kasutaja sekkumist. Pärast seda vältige meediumi allalaadimist tundmatutest ja ebausaldusväärsetest allikatest pärit MMS-sõnumitest.
XDA energiakasutajana saate ka seda teha Stagefrighti keelamiseks tehke oma ehitusrekvisiidis muudatusi. See ei ole täielik ja kindel viis end Stagefrighti eest päästa, kuid võite kasutada oma võimalusi, et vähendada eduka rünnaku tõenäosust, kui olete vanema Androidi järgu juures kinni. Samuti on kohandatud ROM-lahendusi, millest enamik sünkroonib allikaid regulaarselt AOSP-ga ja on seega kaasatud Stagefrighti parandused. Kui kasutate AOSP-põhist ROM-i, on tungivalt soovitatav värskendada ROM-i uuemale versioonile, mis sisaldab Stagefrighti plaastreid. Sa võid kasutada see rakendus et kontrollida, kas Stagefright mõjutab teie praegust igapäevast juhti.
Android, Post-Stagefright
Stagefright pole olnud midagi muud kui äratuskõne Androidile ja selle killustatuse probleemile ning värskendustele. See rõhutab, kuidas puudub selge mehhanism, mille abil saaks selliseid kriitilisi parandusi õigeaegselt paljudes seadmetes kasutusele võtta. Kuigi originaalseadmete tootjad üritavad seadmete jaoks plaastreid välja pakkuda, on karm tõde see, et enamik neist parandustest piirdub ainult hiljutiste lipulaevadega. Muud mittelipulaevad ja vanemad seadmed, veelgi vähem väiksemate originaalseadmete valmistajate seadmed, puutuvad jätkuvalt kokku Stagefrighti sarnastega.
Sellel ärakasutamisel on hõbedane vooder: see juhtis tähelepanu Androidi värskendusprotsessile ja tõstis selle valgusesse, mis ei meelita nii palju tulevasi ettevõtteid Androidi ettevõttes kasutuselevõtule. Kuna Google töötab ettevõtte suurema kasutuselevõtu nimel, on ta sunnitud oma värskendusstrateegia ja originaalseadmete tootjatele võimaldatava kontrolli ümber mõtlema.
Kuna Android M jõuab turule iga päevaga lähemale, poleks üllatav, kui Google otsustaks oma Play teenuste paketi kasuks üha enam AOSP komponente eraldada. Lõppude lõpuks on see valdkond, mille üle Google'il on endiselt täielik kontroll, kui seade tarnitakse koos Google Play poega. See on omad varjuküljed avatud lähtekoodiga alade asendamise näol lähedaste seintega.
Androidi tulevikuga spekuleerides on (väga väike) võimalus, et Google võib piirata ka muudatusi, mida OEM-id AOSP-s teha saavad. Koos RRO raamistik Kuna see on Android M-s funktsionaalses olekus, võib Google piirata originaalseadmete tootjaid, et nad teeksid ainult kosmeetilisi muudatusi RRO-kestade kujul. See peaks võimaldama värskenduste kiiremat juurutamist, kuid see oleks seotud sellega, et originaalseadmete tootjatel ei anta võimalust Androidi täielikult kohandada.
Teine võimalus, mis võib olla võimalik, oleks muuta see kohustuslikuks kõigi tarnitavate seadmete jaoks Google Play poodi, et saada garanteeritud turvavärskendusi kindlaksmääratud ajavahemikuks, võib-olla kaheks aastat. Play teenuste raamistikku saab kasutada oluliste turvavärskenduste ja paikade olemasolu kontrollimiseks, kusjuures Play poe juurdepääs tühistatakse, kui see ei vasta nõuetele.
Lõppmärkused
See on parimal juhul endiselt spekulatsioon, kuna selle probleemi lahendamiseks pole elegantset viisi. Kui väga totalitaarsest lähenemisviisist välja arvata, on paranduste ulatuses alati puudujääke. Android-seadmete arvukuse tõttu oleks iga seadme turvalisuse oleku jälgimine väga hiiglaslik ülesanne. Tunni vajadus on Androidi värskendamisviisi ümbermõtestamine, kuna praegune viis pole kindlasti parim. Meie, XDA Developers, loodame, et Android jääb endiselt truuks oma avatud lähtekoodiga juurtele, töötades koos Google'i suletud lähtekoodiga plaanidega.
Kas teie telefon on Stagefrighti suhtes haavatav? Kas arvate, et teie telefon saab kunagi Stagefrighti plaastri? Andke meile allolevates kommentaarides teada!