Stagefright on yksi huonoimmista Androidin viime aikoina näkemistä hyväksikäytöistä. Napsauta lukeaksesi lisää yksityiskohdista ja tietääksesi kuinka suojautua!
Yksi Androidin vahvimmista kohdista on ensisijaisesti ollut sen avoimen lähdekoodin luonne, jonka ansiosta sidosryhmät voivat haaroittaa, muokata ja jakaa käyttöjärjestelmää uudelleen omaan tarpeeseensa sopivalla tavalla. Mutta tämä avoimen lähdekoodin etu toimii kuin kaksiteräinen miekka haittaohjelmien ja turvallisuuden suhteen. Vikojen löytäminen ja korjaaminen on helpompaa, kun projektissa on paljon päteviä avustajia, joiden lähdekoodi on vapaasti saatavilla. Ongelman korjaaminen lähdetasolla ei kuitenkaan usein johda ongelman korjaamiseen loppukuluttajan käsissä. Sellaisenaan Android ei ole ensisijainen valinta, kun on valittava käyttöjärjestelmä tietoherkän yrityksen tarpeisiin.
Google I/O 2014 -tapahtumassa Google antoi ensimmäisen sysäyksensä kohti turvallisempaa ja yritysystävällisempää ekosysteemiä julkistamalla Android for Work -ohjelma
Turvallisen Androidin tavoittelu ei ole täysin Googlen työtä, sillä Samsungilla on ollut tässä melko merkittävä rooli sen kautta KNOX osallistuu AOSP: hen, joka lopulta vahvistettu Android For Work. Androidin viimeaikaiset tietoturvahyökkäykset ja haavoittuvuudet viittaavat kuitenkin ylämäkeen, kun kyse on suosiosta yrityskäyttöön. Esimerkkinä on viimeaikainen Stagefright-haavoittuvuus.
Sisällys:
- Mikä on Stagefright?
- Kuinka vakava Stagefright on?
- Mikä tekee Stagefrightista eron muista "massiivisista haavoittuvuuksista"?
- Päivitys dilemma
- Android, Post-Stagefright
- Loppuhuomautukset
Mikä on Stagefright?
Yksinkertaisesti sanottuna Stagefright on hyväksikäyttö, joka käyttää koodikirjastoa median toistoon Androidissa nimeltä libstagefright. Libstagefright-moottoria käytetään MMS-viestillä haitallisen videon muodossa vastaanotetun koodin suorittamiseen, jolloin onnistuneen hyökkäyksen suorittamiseen tarvitaan vain uhrin matkapuhelinnumero.
Otimme yhteyttä sisäiseen asiantuntijaamme, XDA Senior Recognized Developeriin ja Developer Adminiin pulseri_g2 antaaksesi tarkemman selityksen.
"Tätä kirjoittaessani [Stagefrightin] hyväksikäyttö oli tarkoitus selittää BlackHatissa [Linkki], vaikka dioja tai valkoisen paperin tietoja ei ole vielä saatavilla.
Siksi annan tämän selityksen enemmän karkeana käsityksenä siitä, mitä on meneillään, enkä syvällisenä selityksenä täydellä tarkkuudella jne.
Stagefrightissa on useita erilaisia bugeja, ja näillä on oma CVE [Yleiset haavoittuvuudet ja altistukset] numerot seurantaa varten:
- CVE-2015-1538
- CVE-2015-1539
- CVE-2015-3824
- CVE-2015-3826
- CVE-2015-3827
- CVE-2015-3828
- CVE-2015-3829
Valitettavasti saatavilla olevia korjaustiedostoja ei ole linkitetty suoraan jokaiseen CVE: hen (kuten niiden pitäisi olla), joten tämä on hieman sotkuinen selittää.
1. [CVE-2015-1538]
MPEG4-käsittelykoodissa 3GPP-metadata (muotoa ja muuta lisätietoa kuvaava juttu, kun video on 3GPP-muodossa) käsittelykoodi on buginen. Se ei hylännyt metatietoja, joissa tiedot olivat liian suuria, vaan vain tarkistavat, olivatko ne liian pieniä. Tämä tarkoitti, että hyökkääjä saattoi luoda "muokatun" tai "vioittuneen" tiedoston, jossa olisi pidempi metatieto-osio kuin sen pitäisi.
Yksi suurimmista haasteista koodin kirjoittamisessa käsittelemään "epäluotettavaa" dataa (eli käyttäjältä tai mistä tahansa muusta koodisi ulkopuolisesta paikasta) on muuttuvan pituuden datan käsittely. Videot ovat tästä täydellinen esimerkki. Ohjelmiston on varattava muistia dynaamisesti riippuen siitä, mitä tapahtuu.
Tässä tapauksessa puskuri luodaan osoittimeksi johonkin muistiin, mutta sen osoittaman taulukon pituus oli yhden elementin liian lyhyt. Tämän jälkeen metatiedot luettiin tähän taulukkoon, ja oli mahdollista, että tämän taulukon viimeinen merkintä ei ollut "nolla" (tai nolla). On tärkeää, että taulukon viimeinen kohde on nolla, koska niin ohjelmisto kertoo taulukon olevan valmis. Pystymällä tekemään viimeisestä arvosta ei-nolla (koska taulukko oli mahdollisesti yksi elementti liian pieni), toinen koodin osa voi lukea haitallisen koodin ja lukea liian paljon dataa. Sen sijaan, että pysähtyisi tämän arvon lopussa, se voisi jatkaa lukemista muihin tietoihin, joita sen ei pitäisi lukea.
(Viite: OmniROM Gerrit)
2. [CVE-2015-1539]
Metatiedon lyhin mahdollinen "koko" tulee olla 6 tavua, koska se on UTF-16-merkkijono. Koodi ottaa kokonaisluvun arvon koon ja vähentää siitä 6. Jos tämä arvo olisi pienempi kuin 6, vähennys "alivuoto" ja kietoutuisi, ja lopputulos olisi erittäin suuri. Kuvittele, että voit esimerkiksi laskea vain 0:sta 65535:een. Jos otat luvun 4 ja vähennät 6, et voi mennä nollan alapuolelle. Joten palaat numeroon 65535 ja lasket sieltä. Sitä täällä tapahtuu!
Jos vastaanotettiin alle 6 pituuden, se voi johtaa kehysten virheelliseen dekoodaukseen, koska byteswap-prosessissa käytetään muuttujaa len16, jonka arvo saadaan laskelmalla, joka alkaa (koko-6). Tämä voi saada aikaan paljon suuremman swap-operaation kuin oli tarkoitettu, mikä muuttaisi arvoja kehystiedoissa odottamattomalla tavalla.
(Viite: OmniROM Gerrit)
3. [CVE-2015-3824]
Iso jätkä! Tämä on ilkeä. Tässä viimeisessä ongelmassa on täsmälleen päinvastoin - kokonaislukujen ylivuoto, jossa kokonaisluvusta voi tulla "liian suuri". Jos saavutat 65535 (esimerkiksi) etkä voi laskea enempää, pyöräydyt ja siirryt seuraavaksi 0:aan!
Jos varaat muistia tämän perusteella (mitä Stagefright tekee!), taulukossa on aivan liian vähän muistia. Kun tietoja lisättiin tähän, se mahdollisesti korvaisi asiaankuulumattomat tiedot haitallisen tiedoston luojan hallitsemilla tiedoilla.
(Viite: OmniROM Gerrit)
4. [CVE-2015-3826]
Toinen ilkeä! Hyvin samanlainen kuin viimeinen - toinen kokonaisluku ylivuoto, jossa taulukko (jota käytetään puskurina) tehtäisiin liian pieneksi. Tämä mahdollistaisi riippumattoman muistin päällekirjoittamisen, mikä taas on huono. Joku, joka osaa kirjoittaa tietoja muistiin, voi vioittaa muita tietoja, jotka eivät liity toisiinsa, ja mahdollisesti käyttää tätä saadakseen puhelimesi suorittamaan hallitsemansa koodin.
(Viite: OmniROM Gerrit)
5. [CVE-2015-3827]
Aika samanlaisia kuin nämä viimeiset. Muuttujaa käytetään, kun ohitetaan jonkin muistin yli, ja tämä voidaan tehdä negatiiviseksi vähennyksen aikana (kuten edellä). Tämä johtaisi erittäin suureen "ohitus"-pituuteen, joka ylittää puskurin ja antaisi pääsyn muistiin, jota ei pitäisi käyttää.
(Viite: OmniROM Gerrit)
On myös joitain (mahdollisesti) liittyviä korjauksia, jotka näyttävät päässeet myös [Android] 5.1:een.
(Viite: OmniROM Gerrit)
Tämä lisää tarkistuksia, joilla estetään aiemman tietoturvakorjauksen ongelmat ja lisätään rajojen tarkistuksia, jotka voivat ylittää. C: ssä numerot, jotka voidaan esittää signed int, tallennetaan signed int. Muuten ne pysyvät ennallaan toiminnan aikana. Näissä tarkistuksissa jotkin kokonaisluvut olisi voitu tehdä etumerkeiksi (eikä etumerkittämättömiksi), mikä pienentäisi niiden maksimiarvoa myöhemmin ja mahdollistaisi ylivuodon.
(Viite: OmniROM Gerrit)
Muutamia lisää kokonaislukujen alivuotoa (jos luvut ovat liian pieniä, ja sitten niistä suoritetaan vähennys, jolloin ne voivat muuttua negatiivisiksi). Tämä taas johtaa suureen määrään eikä pienen, ja se aiheuttaa samat ongelmat kuin edellä.
(Viite: OmniROM Gerrit)
Ja lopuksi toinen kokonaisluku ylivuoto. Sama kuin ennenkin, sitä tullaan käyttämään muualla, ja se voi vuotaa yli.
(Viite: OmniROM Gerrit)"
Kuinka vakava Stagefright on?
Kuten mukaan blogipostaus emotutkimusyhtiö Zimperium Research Labsin julkaisema Stagefrightin hyväksikäyttö saattaa paljastaa 95 % Android-laitteista – noin 950 miljoonaa – tähän haavoittuvuuteen, koska se vaikuttaa laitteisiin, joissa on Android 2.2 ja ylös. Vielä pahempaa on, että Jelly Bean 4.3:aa edeltävät laitteet ovat "pahimmassa riskissä", koska ne eivät sisällä riittäviä lievennyksiä tätä hyväksikäyttöä vastaan.
Mitä tulee vahinkoon, jonka Stagefright voisi aiheuttaa, pulser_g2 huomautti:
[blockquote author="pulser_g2"]"Stagefright antaisi sinänsä pääsyn järjestelmän käyttäjälle puhelimessa. Sinun on kuitenkin ohitettava ASLR (osoitetilan asettelun satunnaistaminen), jotta voit käyttää sitä väärin. Onko tämä saavutettu vai ei, ei tällä hetkellä tiedetä. Tämä hyväksikäyttö mahdollistaa "mielivaltaisen koodin" suorittamisen laitteellasi järjestelmän tai median käyttäjänä. Niillä on pääsy laitteen ääneen ja kameraan, ja järjestelmän käyttäjä on loistava paikka käynnistää pääkäyttäjän hyväksikäyttö. Muistatko kaikki hämmästyttävät pääkäyttäjän oikeudet, joita käytit roottaessasi puhelimesi?
Niitä voitaisiin mahdollisesti käyttää hiljaa juurruttamaan laitteellesi! Se, jolla on root, omistaa puhelimen. Heidän täytyisi ohittaa SELinux, mutta TowelRoot onnistui siinä, ja myös PingPong on onnistunut. Kun he saavat rootin, kaikki puhelimesi on heille avoinna. Viestit, avaimet jne."[/blockquote]
Pahimmista tapauksista puhuttaessa koodin toimittamiseen ja tämän hyväksikäytön käynnistämiseen tarvitaan vain MMS. Käyttäjä viestiä ei tarvitse edes avata koska monet viestintäsovellukset esikäsittelevät MMS-viestin ennen kuin käyttäjä on vuorovaikutuksessa sen kanssa. Tämä eroaa keihään kalasteluhyökkäyksistä, koska käyttäjä voi olla täysin tietämätön onnistuneesta hyökkäyksestä, mikä vaarantaa kaikki puhelimen nykyiset ja tulevat tiedot.
Mikä tekee Stagefrightista eron muista "massiivisista haavoittuvuuksista"?
"Kaikki haavoittuvuudet aiheuttavat jonkin verran riskiä käyttäjille. Tämä on erityisen riskialtista, koska jos joku löytää tavan hyökätä sitä vastaan etänä (mikä on mahdollista, jos kiertotie ASLR löydettiin), se voi laukaista ennen kuin edes huomaat olevasi alle hyökkäys"
Vanhemmat hyväksikäytöt, kuten Android Installer Hijacking, FakeID sekä root-hyökkääjät, kuten TowelRoot ja PingPong, vaativat jossain vaiheessa käyttäjän toimia, jotta ne voidaan suorittaa. Vaikka ne ovat edelleen "hyödynnyksiä" siinä tosiasiassa, että haitallisesta käytöstä voi aiheutua paljon haittaa, tosiasia on, että Stagefright tarvitsee teoriassa vain uhrin matkapuhelinnumeron muuttaakseen puhelimensa troijalaiseksi, ja siksi siihen on kiinnitetty niin paljon huomiota viime aikoina. päivää.
Android ei kuitenkaan ole täysin tämän hyväksikäytön armoilla. Android Securityn johtava insinööri Adrian Ludwig käsitteli joitakin huolenaiheita a Google+ -viesti:
[blockquote author="Adrian Ludwig"]"On yleinen, virheellinen oletus, että mikä tahansa ohjelmistovirhe voidaan muuttaa tietoturvan hyväksikäytöksi. Itse asiassa useimpia bugeja ei voi hyödyntää, ja Android on tehnyt monia asioita parantaakseen näitä kertoimia...
Luettelo joistakin teknologioista, jotka on otettu käyttöön Ice Cream Sandwichin (Android 4.0) jälkeen tässä. Tunnetuin näistä on nimeltään Address Space Layout Randomization (ASLR), joka valmistui kokonaan Android 4.1:ssä PIE-tuella (Position Independent Executables) ja on nyt yli 85 %:ssa Androidista laitteet. Tämän tekniikan ansiosta hyökkääjän on vaikeampi arvata koodin sijainti, jota tarvitaan onnistuneen hyväksikäytön rakentamiseen...
Emme lopettaneet ASLR: ää, vaan olemme lisänneet myös NX: n, FortifySourcen, Read-Only-Relocationsin, Stack Canariesin ja paljon muuta."[/blockquote]
Silti ei voida kiistää sitä, että Stagefright on vakava asia Androidin tulevaisuuden kannalta, ja siksi mukana olevat sidosryhmät ottavat sen vakavasti. Stagefright korosti myös valkoisia norsuja huoneessa – pirstoutumisen ja kuluttajan vihdoin saapuvien päivitysten ongelman.
Päivitys dilemma
Päivityksistä puheen ollen on hyvä huomata, että OEM-valmistajat ottavat vastuuta käyttäjien turvallisuudesta, kuten monet ovat luvanneet parantaa päivitysprosessia erityisesti tietoturvakorjausten ja -päivitysten sisällyttämiseksi Stagefrightin kaltaisiin hyväksikäyttöihin.
Google on luvannut ensimmäisten joukossa, jotka julkaisivat virallisen lausunnon kuukausittaiset tietoturvapäivitykset (suunniteltujen käyttöjärjestelmä- ja alustapäivitysten lisäksi) useimmille sen Nexus-laitteille, mukaan lukien lähes 3 vuotta vanha Nexus 4. Samsung on myös seurannut esimerkkiä ilmoittamalla, että se tekee yhteistyötä operaattorien ja kumppaneiden kanssa toteuttaakseen a kuukausittainen tietoturvapäivitysohjelma mutta se ei pystynyt määrittelemään tämän toteutuksen laitteita ja aikajanan yksityiskohtia. Tämä on mielenkiintoista, koska siinä mainitaan "nopeutettu" lähestymistapa tietoturvapäivityksiin yhteistyössä operaattorien kanssa, joten voimme odottaa useammin päivityksiä (tosin tietoturvapohjaisia, mutta toivottavasti se myös nopeuttaa laiteohjelmiston päivityksiä) operaattorilta laitteet.
Muita pakettiin liittyviä OEM-valmistajia ovat LG, joka liittyy mukaan kuukausittaiset tietoturvapäivitykset. Motorola on myös ilmoittanut päivitettävien laitteiden luettelo Stagefright-korjauksilla, ja luettelo sisältää lähes kaikki laitteet, joita yritys on valmistanut vuodesta 2013 lähtien. Sony on myös sanonut tämän sen laitteet saavat pian korjaustiedostot liian.
Kerrankin myös operaattorit saavat päivityksiä. Sprintillä on antoi lausunnon että jotkut laitteet ovat jo saaneet Stagefright-korjauksen, ja lisää laitteita on ajoitettu päivitykseen. Myös AT&T on seurannut esimerkkiä julkaisemalla korjaustiedoston joillekin laitteille. Verizon on myös julkaissut korjaustiedostoja, vaikkakin tämä on hidas käyttöönotto, joka asettaa etusijalle huippuluokan älypuhelimet, kuten Galaxy S6 Edge ja Note 4. T-Mobile Note 4 sai myös Stagefright-korjauspäivityksen.
Loppukäyttäjänä on olemassa muutamia varotoimenpiteitä, joilla voit vähentää mahdollisuuksiasi joutua hyökkäyksen kohteeksi. Ensinnäkin poista MMS-viestien automaattinen haku puhelimesi viestisovelluksista. Tämän pitäisi pitää hallinnassa tapaukset, joissa hyväksikäytön toimiminen ei edellytä käyttäjän toimia. Varmista tämän jälkeen, ettet lataa mediaa tuntemattomista ja epäluotettavista lähteistä peräisin olevista MMS-viesteistä.
XDA-tehokäyttäjänä voit myös tee muokkauksia rakennustarpeeseesi poistaaksesi Stagefrightin käytöstä. Tämä ei ole täydellinen ja varma tapa pelastaa itsesi Stagefrightilta, mutta voit käyttää mahdollisuutesi vähentääksesi onnistuneen hyökkäyksen todennäköisyyttä, jos olet jumissa vanhemmassa Android-versiossa. On myös mukautettuja ROM-ratkaisuja, joista useimmat synkronoivat lähteet AOSP: n kanssa säännöllisesti ja sisältävät siten Stagefright-korjaukset. Jos käytät AOSP-pohjaista rom-levyä, on erittäin suositeltavaa päivittää ROM-levyn uudempaan versioon, joka sisältää Stagefright-korjaukset. Voit käyttää tämä sovellus tarkistaaksesi, vaikuttaako Stagefright nykyiseen päivittäiseen kuljettajaasi.
Android, Post-Stagefright
Stagefright on ollut vain herätys Androidille ja sen pirstoutumis- ja päivitysongelmalle. Se korostaa, ettei ole olemassa selkeää mekanismia, jonka avulla tällaiset kriittiset korjaukset voidaan ottaa käyttöön ajoissa useisiin laitteisiin. Vaikka OEM-valmistajat yrittävät julkaista korjaustiedostoja laitteille, karu totuus on, että useimmat näistä korjauksista rajoittuvat vain uusimpiin lippulaivoihin. Muut ei-lippulaivat ja vanhemmat laitteet, varsinkin pienemmiltä OEM-valmistajilta, ovat edelleen alttiina Stagefrightin kaltaisille.
Tässä hyväksikäytössä on hopeinen vuoraus: Se kiinnitti uudelleen huomion Androidin päivitysprosessiin ja esitti sen valossa, joka ei houkuttele niin monia tulevia yritysyrityksiä ottamaan Androidin käyttöön yrityskäyttöön. Kun Google pyrkii lisäämään yritysten käyttöönottoa, sen on pakko harkita uudelleen päivitysstrategiaansa ja OEM-valmistajille mahdollistaman hallinnan määrää.
Android M: n lähestyessä markkinoiden julkaisua päivä päivältä ei olisi yllätys, jos Google päättäisi irrottaa yhä useammat AOSP: n komponentit Play-palvelupaketin hyväksi. Loppujen lopuksi tämä on alue, jota Google edelleen hallitsee, jos laite toimitetaan Google Play Kaupan mukana. Tämä on omat huonot puolensa korvaamalla avoimen lähdekoodin alueet läheisillä seinillä.
Androidin tulevaisuutta spekuloitaessa on (erittäin pieni) mahdollisuus, että Google saattaa myös rajoittaa OEM-valmistajien AOSP: lle tekemiä muutoksia. Kanssa RRO-kehys Koska se on Android M: ssä toimivassa tilassa, Google voisi rajoittaa OEM-valmistajia tekemään vain kosmeettisia muutoksia RRO-skinien muodossa. Tämän pitäisi mahdollistaa nopeampi päivitysten käyttöönotto, mutta sen kustannuksella OEM-valmistajilta evätään mahdollisuus muokata Androidia täysin.
Toinen mahdollinen vaihtoehto olisi tehdä siitä pakollinen kaikille toimitettaville laitteille Google Play Kauppa saadaksesi taattuja tietoturvapäivityksiä tietyn ajanjakson ajan, mahdollisesti kahdeksi vuotta. Play Services -kehystä voitaisiin käyttää tärkeiden tietoturvapäivitysten ja -korjausten tarkistamiseen, ja Play Kaupan käyttöoikeus peruutetaan, jos sääntöjä ei noudateta.
Loppuhuomautukset
Tämä on parhaimmillaan edelleen spekulaatiota, koska ongelman ratkaisemiseksi ei ole tyylikästä tapaa. Hyvin totalitaarista lähestymistapaa lukuun ottamatta korjausten ulottuvuudessa tulee aina olemaan puutteita. Android-laitteiden suuresta määrästä johtuen jokaisen laitteen suojauksen tilan seuraaminen olisi erittäin jättimäinen tehtävä. Tunnin tarve on Androidin päivitystavan uudelleen miettiminen, koska nykyinen tapa ei todellakaan ole paras. Me XDA Developersissä toivomme, että Android pysyy edelleen uskollisena avoimen lähdekoodin juurilleen työskennellessään yhdessä Googlen suljetun lähdekoodin suunnitelmien kanssa.
Onko puhelimesi alttiina Stagefrightille? Luuletko, että puhelimesi saa koskaan Stagefright-korjauksen? Kerro meille alla olevissa kommenteissa!