Googlen Project Zero löysi kuinka ohittaa Samsungin Knox Hypervisor (korjattu tammikuussa)

Uusimmassa Project Zero -blogiviestissä tiimi on löytänyt tavan ohittaa Samsungin reaaliaikainen ydinsuojaus, nimeltään Knox Hypervisor.

Googlen Project Zero -tiimi on vahvistanut useita hyväksikäyttöjä, joiden avulla Samsungin puhelimia, joissa oletettavasti suojattua Samsung Knox -tietoturvaohjelmistoa käytetään, voidaan hyökätä. Blogissa todetaan, että kaikki haavoittuvuudet on välitetty Samsungille, joka on itse asiassa julkaissut korjauksia niihin tammikuun ohjelmistopäivityksessä.


Tausta

Osana Samsungin esittelemää Samsung Knox -tietoturvaohjelmistopakettia Android-sovellusten ja ytimen välissä on ohjelmisto, jota kutsutaan nimellä Hypervisor. Tätä voidaan käyttää lisäkerroksena Android-laitteiden suojaamiseen. Samsung Knox Hypervisor on nimeltään "Reaaliaikainen ytimen suojaus" tai lyhyesti RKP, kuten viittaan siihen tämän artikkelin loppuosassa.

Kernel sijaitsee RKP: n alapuolella Android-ohjelmistopinossa, ja laitteella toimivat sovellukset ovat yläosassa. RKP: n ideana on tarjota ylimääräinen suojakerros laitteelle, koska kaikki pyynnöt (muisti ja muut resurssit) Ytimen sovellusten on ensin läpäistävä Knox, joka yrittää havaita, tekeekö sovellus jotain sille ei pitäisi. RKP tarjoaa myös turvallisuutta epäselvyyden kautta ylimääräisellä kerroksella, joka piilottaa arkaluontoiset tiedot, joita sovellus voi käyttää laitteen vaarantamiseen.

Blogitekstissä käsitellään melko syvästi Android-muistin, RKP: n ja käyttöjärjestelmien toimintaa, joten olen tiivistänyt ja yksinkertaistanut sen antaakseni nopean yleiskatsauksen siitä, mitä löydettiin. Suosittelen kuitenkin lukemaan koko artikkelin, jos sinulla on aikaa, sillä se on erittäin valaiseva.


Hyödynnä #1:

KASLR tai Kernel Address Space Layout Randomization on prosessi, jossa ytimen koodin sijaintia muutetaan satunnaisella määrällä muistissa käynnistyksen yhteydessä. Joka kerta kun laite käynnistetään, ydin ladataan eri osoiteavaruuteen (muistin alueelle). Ajatuksena on vaikeuttaa ytimen koodin sijaintipaikan löytämistä, jotta sitä voidaan hyökätä, koska jokaisen käynnistyksen jälkeen ytimen koodi "siirtyy" satunnaisen määrän muistissa. Tämä kuulostaa hienolta askeleelta mahdollisten hyökkääjien estämiseksi, mutta äskettäin tutkimusta on osoittanut, että voit itse asiassa voittaa tämän ilman ohjelmistovirhettä tai haavoittuvuutta, koska KASLR on itse asiassa erittäin vaikea toteuttaa vahvasti paikallisia hyökkääjiä vastaan.

RKP-ohjelmiston tapauksessa kyky ohittaa KASLR on itse asiassa yksinkertaisempi kuin yllä viitattu tutkimus. Kaikkien Android-laitteiden muistiin viitataan osoittimilla ja laitteiden suojaamiseksi hyökkäyksiltä aina, kun Android-laitteet tulostavat tai tulostavat (joko näyttöä tai tallentaa lokeja tai virheenkorjausta), osoittimien viittaukset anonymisoidaan, - jolloin on mahdotonta saada selville, mihin osoitin todella osoittaa, kun luet ulostulo.

Ajattele muistiosoittimia, kuten katukylttiä, joka osoittaa sijaintiin, ja ajattele anonymisointia sen hämärtävänä. Aivan kuten televisiossa, anonymisointi tehdään kuvauksen jälkeen, myös Android käyttää tätä anonymisointia tulostushetkellä ja vain, jos anonymisointi on määritetty oikein, ja kirjoittaja toteaa. että jokaisessa [hänen] kohtaamassa laitteessa osoittimen anonymisointi on määritetty oikein. Tämä saattaa kuulostaa siltä, ​​että sitä on erittäin vaikea rikkoa, mutta sinun tarvitsee vain löytää yksi osoitin (ajattele katukylttiä), jota ei ole anonymisoitu (sumentunut) ytimen kehittäjä (varo, että tämä ei ole tavallinen Android-sovelluskehittäjäsi), kun osoitin kirjoitetaan lokeihin tai muuhun paikkaan, esim. näyttö tai a tiedosto.

Joten jos löydät osoittimen, jota ei ole tehty nimettömäksi, voit laskea ytimen satunnaisen osoitteensiirron näiden kahden erona. Mielenkiintoista, että kirjoittaja ei löytänyt hyödynnettävää osoitinta ytimestä, mutta löysi sen RPK: sta jossa kehittäjät unohtivat anonymisoida osoittimen virheenkorjaus (loki) -tulostuksessa, mikä syntyi kirjoitusvirhe. Androidin osoittimien anonymisoimiseksi sinun on käytettävä erityistä koodia, ja käy ilmi, että RPK-kehittäjät käyttivät virheellisesti pienet kirjaimet "k" sijasta an isot kirjaimet K. Siksi oli suhteellisen helppoa selvittää ytimen koodin satunnainen siirtomäärä ja hyökätä sitä vastaan.


Hyökkäys #2:

Seuraava hyöty on hieman monimutkaisempi: Samsung Knox suojaa laitettasi soveltamalla sääntöjä laitteen muistiin estääkseen haitallisen koodin. Säännöt ovat seuraavat:

  1. Kaikki sivut (muistissa oleva koodi), ytimen koodia lukuun ottamatta, on merkitty "Etuoikeutettu suorittamaan ei koskaan" (tämä tarkoittaa, että koodia ei voi koskaan suorittaa)
  2. Ytimen tietosivuja (ohjelman muistissa käyttämät tiedot) ei koskaan merkitä suoritettaviksi (joten tässä oleva koodi ei voi koskaan toimia)
  3. Ytimen koodisivuja (koodi muistissa) ei ole koskaan merkitty kirjoitettaviksi (joten mikään haitallinen koodi ei voi muuttaa sitä)
  4. Kaikki ytimen sivut on merkitty vain luku -muotoisiksi vaiheen 2 käännöstaulukossa (taulukko, joka sijaitsee sovelluksen ja ytimen välissä estääkseen sovelluksia tiedosta todellisia muistipaikkoja)
  5. Kaikki muistin käännösmerkinnät on merkitty sovelluksille vain luku -muotoisiksi.

Keskitymme sääntöön 3, koska tässä kirjoittaja havaitsi ongelman yllä olevien sääntöjen täytäntöönpanossa. RPK itse asiassa merkitsee ytimen muistin vain luku -muotoiseksi, mutta KASL: n häiriönä havaittiin aukko, joka johti kirjoittamalla koodia oletettavasti "vain luku" -osioon. Ytimen sijainnin hämärtämiseksi käynnistyksen yhteydessä ytimelle varataan muistia, mutta tämä muistimäärä on paljon suurempi kuin ytimen tekstisegmentti. Varaamalla suurempi määrä muistia se vaikeuttaa todellisen ytimen koodin löytämistä, joka voisi olla missä tahansa, ja kuten yllä näimme, sitä siirretään satunnaisesti laitteen jokaisessa käynnistyksessä.

_text ja _etext merkitsevät suojatun alueen

Kirjoittaja pystyi vahvistamaan, että ytimen käyttämä muisti oli todellakin merkitty "vain luku", mutta loput ytimen piilottamiseen käytetystä suuresta muistista oli ei merkitty "vain luku". Tämä johtuu siitä, että RKP suojaa vain ytimen tekstin sisältävää aluetta KASLR-dian käyttöönoton jälkeen.


Hyödynnä #3

Kolmannessa hyväksikäytössä kirjoittaja pääsi toiselle muistialueelle, joka tulisi myös rajoittaa vain luku -tilaan. RKP suojaa muistia ja käyttää a Hypervisor-määritysrekisteri (HCR) ohjaamaan keskeisiä ydintoimintoja. HCR: n tarkoitus on sallia kelvollisten ja todellisten ydintoimintojen pääsy rekistereihin ja estää haitalliset hyökkäykset. Se tekee tämän tarkistamalla virtualisointiominaisuuksia hallitseviin rekistereihin tehdyt kutsut. HCR on määritetty estämään tietyt toiminnot, jotka käsitellään normaalisti, jolloin RKP voi valita, sallitaanko vai hylätäänkö pyyntö.

Tässä hyväksikäytössä HCR: n ohjaus oli ei kata kahta rekisteriä se osoittautui erittäin tärkeäksi. Kirjoittaja kaivautui syvälle ARM Reference -oppaaseen ja huomasi, että ensimmäinen rekisteri antoi hänelle mahdollisuuden sammuttaa RKP: n periaatteessa sovelluksille. "System Control Register for EL1 (SCTLR_EL1) tarjoaa ylimmän tason järjestelmän, mukaan lukien muistijärjestelmän, ohjauksenTäydellisessä maailmassa sovellus käyttäisi muistia, joka on kartoitettu RKP: n kautta, jotta RKP voisi hallita, mitä sovellus voi käyttää. Tämän rekisterin poistaminen käytöstä salli kuitenkin RKP poistetaan käytöstä palauttamalla laitteen tehokkaasti siihen, miten se toimi ennen RKP: n asentamista – mikä tarkoittaa, että laite on kartoitettu fyysiseen muistiin ilman RKP: n tarjoamaa ylimääräistä suojausta. Tämä puolestaan ​​tarkoitti, että kirjoittaja pystyi lukemaan ja kirjoittamaan muistiin, jonka RKP-ohjelmisto alun perin ja oikein esti.

Toisella unohdetulla rekisterillä oli hienovaraisempi vaikutus, mutta lopulta yhtä tuhoisa turvallisuuden kannalta. The Käännösten valvontarekisteri EL1:lle (TCR_EL1) -rekisteri liittyy suoraan muistin määrään, jolla sovellus toimii, jota kutsutaan sivuksi. RKP on kovakoodattu 4 kt: n sivukokoon, koska AARCH64 Linux -ytimet (kuten Android) käyttävät 4 kt: n käännöskokoa. Kyseinen rekisteri (TCR_EL1) asettaa ARM-piirisarjat palautettavan muistin kokoiseksi. Siitä käy ilmi tämä rekisteri ei ole HCR: n suojaama ja siksi hyökkääjä voi muuttaa sitä samalla tavalla kuin kirjoittaja muutti sen 64 kt: n kokoiseksi.

Tämä tarkoittaa, että kun RKP täyttää pyynnön, käytettävissä olevan muistin todellinen määrä on nyt 64 kt 4 kt: n sijaan. Syynä on se, että ARM-piirisarja hallitsee edelleen sivun kokoa ja se asetettiin 64 kt: ksi hyväksikäytön toimesta. Koska RKP suojelee muistia kirjoitukselta osana hyväksikäytön #2 sääntöjä, muisti on silti tosiasiassa suojattu. Mutta tässä on saalis - koska RKP on kovakoodattu 4 kilotavuun, se ei muutu 64 kt: n sivukooksi, kun rekisteri päivitettiin, joten vain ensimmäiset 4 kt muistia on suojattu antaa hyökkääjän tehdä mitä hän haluaa jäljellä olevilla 60 kb: lla.


Hyödynnä #4

Kirjoittajan viimeinen hyväksikäyttö viittaa muistiin, jossa RKP-ohjelmisto on, jotta hyökkääjä voisi hyökätä itse RKP-ohjelmistoon. Yksi temppu tämäntyyppisten hyökkäysten pysäyttämiseksi, jota myös Linux-ytimet käyttävät, on poistaa ohjelmasi kartta virtuaalisen muistin osoiteavaruudesta, jotta mitkään sovellukset eivät voi hyökätä siihen, koska ne eivät voi viitata siihen.

Muista, että muistissa on kyse osoittimista ja taulukoista, jotka yhdistävät fyysisen muistin virtuaalimuistiin. Tämän tyyppisen hyökkäyksen normaalin puolustuksen mukaisesti RKP purkaa itsensä, jotta sitä ei voida hyökätä. Kuitenkin, jos ydin ei tarjoa tällaisia ​​kykyjä, RKP sallii muistin osan yhdistämisen ja merkitsemisen Read/Writeksi. Ainoa tarkistus on, että se ei ole itse taustalla oleva ydin, koska RKP ei tarkista, ovatko osoitteet, jotka pyydetään kartoittamaan, alue, jossa RKP itse sijaitsee muistissa. Periaatteessa RKP antaa itsensä kartoittua uudelleen takaisin osoiteavaruuteen, jota sovellukset voivat käyttää, ja sivuna vaikuttaa muisti merkitään automaattisesti Read/Write joten hyökkääjä voi nyt käyttää muistia miten haluaa.


Johtopäätös

Yksi suurimmista ongelmista edellä lueteltujen neljän hyväksikäytön kanssa on se, että kirjoittaja mainitsee, kuinka vaikeita nämä olisivat suorittaa Android-perusytimen toimintojen puutteen vuoksi. Ironista kyllä, suojattu RKP Hypervisor tarjosi kaikki hyökkäysten suorittamiseen tarvittavat työkalut. Se osoittaa, että joskus hyvää tarkoittavat ohjelmistot aiheuttavat enemmän ongelmia kuin ratkaisevat, ja olemme onnekkaita, että meillä on ihmisiä kuten Gal Benimini, joka on valmis likaamaan kätensä ja testaamaan, että dokumentaatio vastaa ohjelmiston todellista sisältöä tekee.

Vaikka nämä hyväksikäytöt näyttävät pelottavilta ja saavat Knoxin kuulostamaan erittäin haavoittuvalta, haluaisin vakuuttaa kaikille, että nämä ongelmat ovat kaikki korjattu tammikuun päivityksessä Samsungilta. Lisäksi nämä hyvät toiminnot vaativat erittäin syvää ARM-prosessorien ja ohjelmoinnin tuntemusta, joten este näiden hyväksikäyttöjen käyttöön on tähtitieteellisesti korkea.


Lähde: Project Zero