Google projekts Zero atklāja, kā apiet Samsung Knox Hypervisor (labots janvāra ielāps)

click fraud protection

Jaunākajā Project Zero emuāra ierakstā komanda ir atklājusi veidu, kā apiet Samsung reāllaika kodola aizsardzību, ko sauc par Knox Hypervisor.

Google Project Zero komanda ir pārbaudījusi vairākus ekspluatācijas veidus, kas ļauj uzbrukt Samsung tālruņiem, kuros darbojas it kā drošais Samsung Knox drošības komplekts. Emuārs norāda, ka visas ievainojamības ir nodotas Samsung, kas faktiski ir izlaidusi to labojumus janvāra programmatūras atjauninājumā.


Fons

Kā daļa no Samsung ieviestā Samsung Knox drošības programmatūras komplekta ir programmatūras daļa, kas atrodas starp Android lietojumprogrammām un kodolu, ko sauc par Hipervizors. To var izmantot kā papildu slāni, lai vēl vairāk aizsargātu Android ierīces. Samsung Knox Hypervisor sauc par "Reāllaika kodola aizsardzība" jeb saīsināti RKP, kā es uz to atsaukšos šī raksta pārējā daļā.

Kodols atrodas zem RKP Android programmatūras kaudzē, un lietojumprogrammas, kas darbojas ierīcē, atrodas augšpusē. RKP ideja ir nodrošināt papildu drošības līmeni ierīcei, jo visi pieprasījumi (atmiņa un citi resursi) lietojumprogrammām kodolam vispirms ir jāiziet caur Knox, kas mēģina noteikt, vai lietojumprogramma kaut ko dara nevajadzētu. RKP nodrošina arī drošību, izmantojot neskaidrību, izmantojot papildu slāni, lai paslēptu sensitīvu informāciju, ko lietojumprogramma varētu izmantot ierīces kompromitēšanai.

Emuāra ziņā ir diezgan dziļi aprakstīts, kā darbojas Android atmiņa, RKP un operētājsistēmas kopumā, tāpēc esmu to saīsinājis un vienkāršojis, lai sniegtu ātru pārskatu par atklāto. Tomēr iesaku izlasīt visu rakstu, ja jums ir laiks, jo tas ir ļoti izglītojošs.


Ekspluatācija Nr. 1:

KASLR jeb Kodola adrešu telpas izkārtojuma izkārtojuma nejaušināšana ir process, kurā sāknēšanas laikā par nejaušu lielumu maina kodola koda atrašanās vietu atmiņā. Katru reizi, kad ierīce tiek sāknēta, kodols tiek ielādēts citā adrešu telpā (atmiņas apgabalā). Ideja ir apgrūtināt kodola koda atrašanu, lai tam uzbruktu, jo pēc katras sāknēšanas kodola kods "izmainās" par nejaušu daudzumu atmiņā. Tas izklausās kā lielisks solis, lai novērstu iespējamos uzbrucējus, taču nesen pētījumiem ir parādījis, ka jūs faktiski varat to pārvarēt, nepieprasot programmatūras kļūdu vai ievainojamību, jo KASLR patiesībā ir ļoti grūti ieviest spēcīgā veidā pret vietējiem uzbrucējiem.

RKP programmatūras gadījumā iespēja apiet KASLR faktiski ir vienkāršāka nekā iepriekš minētais pētījums. Visu Android ierīču atmiņa tiek norādīta ar norādes un, lai aizsargātu ierīces no uzbrukumiem, ikreiz, kad Android ierīces drukā vai izvada (neatkarīgi no tā, vai ekrānā vai lai ierakstītu žurnālus vai atkļūdošanu), norādes atsauces ir anonimizētas, tādējādi lasot izvade.

Padomājiet par atmiņas norādēm, piemēram, ielas zīmi, kas norāda uz atrašanās vietu, un domājiet par anonimizāciju kā tās aizmiglošanu. Līdzīgi kā televīzijā, anonimizācija tiek veikta pēc filmēšanas, Android arī izmanto šo anonimizāciju izvades laikā un tikai tad, ja anonimizācija ir pareizi konfigurēta, un autors norāda ka katrā ierīcē [viņš] ir bijusi pareizi konfigurēta rādītāja anonimizācija. Tas varētu izklausīties tā, ka to ir ļoti grūti salauzt, taču viss, kas jums jādara, ir atrast vienu rādītāju (domājiet par ielas zīmi), kas nav anonimizēts (izplūdis). kodola izstrādātājs (uzmanieties, ka tas nav jūsu vidējais Android lietotņu izstrādātājs), kad rādītājs ir ierakstīts žurnālos vai citā vietā, piemēram, ekrāns vai a failu.

Tātad, ja varat atrast rādītāju, kas nav anonimizēts, varat aprēķināt kodola nejaušo adreses maiņu kā atšķirību starp abiem. Interesanti, ka autors kodolā nevarēja atrast izmantojamu rādītāju, bet atrada to RPK iekšpusē. kur izstrādātāji aizmirsa anonimizēt rādītāju atkļūdošanas (reģistrēšanas) izvadē, kas radās drukas kļūda. Lai anonimizētu norādes operētājsistēmā Android, ir jāizmanto īpašs kods, un izrādās, ka RPK izstrādātāji kļūdaini izmantoja mazie burti "k" vietā an lielie burti "K". Tāpēc bija samērā vienkārši izdomāt kodola koda nejaušo nobīdes apjomu un tam uzbrukt.


2. izmantošana:

Nākamā darbība ir nedaudz sarežģītāka: Samsung Knox aizsargā jūsu ierīci, ierīces atmiņai piemērojot noteikumu kopumu, lai apturētu ļaunprātīgu kodu. Noteikumi ir šādi:

  1. Visas lapas (kods atmiņā), izņemot kodola kodu, ir atzīmētas kā "Privileged Execute Never" (tas nozīmē, ka kodu nekad nevar palaist)
  2. Kodola datu lapas (dati, ko programma izmanto atmiņā) nekad nav atzīmēti kā izpildāmi (tāpēc šeit kodu nekad nevar palaist)
  3. Kodola kodu lapas (kods atmiņā) nekad nav atzīmētas kā rakstāmas (tāpēc neviens ļaunprātīgs kods nevar to mainīt)
  4. Visas kodola lapas ir atzīmētas kā tikai lasāmas 2. posma tulkošanas tabulā (tabulā, kas atrodas starp lietojumprogrammu un kodolu, lai vēl vairāk neļautu lietojumprogrammām uzzināt par reālajām atmiņas vietām).
  5. Visi atmiņas tulkošanas ieraksti lietojumprogrammām ir atzīmēti kā tikai lasāmi.

Mēs pievērsīsimies 3. noteikumam, jo ​​šeit autors atklāja problēmu saistībā ar iepriekš minēto noteikumu ieviešanu. RPK faktiski atzīmē kodola atmiņu kā tikai lasāmu, taču KASL nolaidības dēļ tika atklāts caurums, kas noveda pie rakstot kodu it kā “tikai lasāmā” sadaļā. Lai slēptu kodola atrašanās vietu sāknēšanas laikā, kodolam tiek piešķirta atmiņa, taču šis atmiņas apjoms ir daudz lielāks nekā kodola teksta segments. Piešķirot lielāku atmiņas apjomu, ir daudz grūtāk atrast faktisko kodola kodu, kas varētu būt jebkur, un, kā mēs redzējām iepriekš, tas tiek nejauši pārvietots katrā ierīces sāknēšanas reizē.

_text un _etext atzīmē aizsargāto diapazonu

Autors varēja apstiprināt, ka kodola izmantotā atmiņa patiešām ir atzīmēta kā "tikai lasāma", tomēr pārējā lielā atmiņas apjoma daļa, kas tika izmantota kodola slēpšanai, bija atzīmēts kā "tikai lasāms". Tas ir tāpēc, ka RKP aizsargā reģionu, kurā atrodas kodola teksts, tikai pēc KASLR slaida lietošanas.


Ekspluatācija #3

Trešajā ekspluatācijā autors varēja piekļūt citai atmiņas apgabalam, kas būtu jāierobežo arī tikai lasāmā režīmā. RKP aizsargā atmiņu un izmanto a Hipervizora konfigurācijas reģistrs (HCR), lai kontrolētu galvenās kodola darbības. HCR mērķis ir ļaut derīgām un reālām kodola operācijām piekļūt reģistriem un bloķēt ļaunprātīgus uzbrukumus. Tas tiek darīts, pārbaudot zvanus uz reģistriem, kas regulē virtualizācijas funkcijas. HCR ir konfigurēts, lai bloķētu noteiktas darbības, kas tiktu apstrādātas parasti, ļaujot RKP izvēlēties, vai atļaut vai neatļaut pieprasījumu.

Šajā ekspluatācijā HCR kontrole bija neaptver divus reģistrus kas izrādījās ļoti svarīgi. Autors dziļi iedziļinājās ARM Reference rokasgrāmatā un atklāja, ka pirmais reģistrs ļāva viņam būtībā izslēgt RKP lietojumprogrammām. "Sistēmas vadības reģistrs EL1 (SCTLR_EL1) nodrošina augstākā līmeņa kontroli pār sistēmu, tostarp atmiņas sistēmuIdeālā pasaulē lietojumprogramma izmantotu atmiņu, kas tika kartēta, izmantojot RKP, lai RKP varētu kontrolēt, kam programma var piekļūt. Tomēr šī reģistra izslēgšana ļāva RKP atspējot efektīvi atgriežot ierīci tā, kā tā darbojās pirms RKP instalēšanas – tas nozīmē, ka ierīce tiek kartēta uz fizisko atmiņu bez papildu drošības, ko nodrošina RKP. Tas savukārt nozīmēja, ka autors varēja lasīt un rakstīt atmiņā, kuru sākotnēji un pareizi bloķēja RKP programmatūra.

Otrajam reģistram, kas tika palaists garām, bija smalkāka ietekme, bet galu galā tikpat postoša drošība. The Tulkošanas kontroles reģistrs EL1 (TCR_EL1) reģistrs ir tieši saistīts ar atmiņas apjomu, ar kuru lietojumprogramma strādā, ko sauc par lapu. RKP ir cietais kods, lai lapas izmērs būtu 4 KB, jo AARCH64 Linux kodoli (piemēram, Android) izmanto tulkošanas lielumu 4 KB. Attiecīgais reģistrs (TCR_EL1) iestata ARM mikroshēmojumus uz atgriežamās atmiņas lielumu. Izrādās, ka šo reģistru neaizsargā HCR un tāpēc uzbrucējs to var mainīt, jo autors to mainīja uz 64 kb lielu lapas izmēru.

Tas nozīmē, ka tad, kad RKP izpilda pieprasījumu, faktiskais pieejamās atmiņas apjoms tagad ir 64 kb, nevis 4 kb. Iemesls ir tāds, ka ARM mikroshēmojums joprojām kontrolē lapas lielumu, un tas tika iestatīts uz 64 kb. Tā kā RKP aizsargā atmiņu no ierakstīšanas, kā daļa no 2. ekspluatācijas noteikumiem, atmiņa joprojām ir faktiski aizsargāta. Bet šeit ir āķis — tā kā RKP ir kodēts uz 4 kb, tas nemainās uz 64 kb lapas izmēru, kad reģistrs tika atjaunināts, tāpēc ir aizsargāti tikai pirmie 4 kb atmiņas ļaujot uzbrucējam to darīt ko viņš grib ar atlikušajiem 60kb.


Ekspluatācija #4

Pēdējais autora parādītais izmantojums ir atsauce uz atmiņu, kur atrodas RKP programmatūra, lai uzbrucējs varētu uzbrukt pašai RKP programmatūrai. Viens no trikiem, lai apturētu šāda veida uzbrukumus, ko izmanto arī Linux kodoli, ir atdalīt programmu no virtuālās atmiņas adrešu telpas, lai neviena lietojumprogramma nevarētu tai uzbrukt, jo nevar uz to atsaukties.

Atcerieties, ka atmiņa ir tikai norādes un tabulas, kas savieno fizisko atmiņu ar virtuālo atmiņu. Atbilstoši parastajai aizsardzībai šāda veida uzbrukumos RKP atkarto sevi, lai tai nevarētu uzbrukt. Tomēr, ja kodols nenodrošina šādas iespējas, RKP ļauj kartēt atmiņas daļu un atzīmēt to kā Lasīt/rakstīt. Vienīgā pārbaude ir, vai tas nav pats pamatā esošais kodols, jo RKP nepārbauda, ​​vai adreses, kuras tiek pieprasītas kartēt, ir apgabals, kurā pats RKP atrodas atmiņā. Būtībā RKP ļauj sevi atkārtoti kartēt atpakaļ adreses telpā, kurai var piekļūt lietojumprogrammas, un kā sānu ietekmēt atmiņa tiek automātiski atzīmēta kā lasīšana/rakstīšana tāpēc uzbrucējs tagad var izmantot atmiņu, kā vien vēlas.


Secinājums

Viena no lielākajām problēmām saistībā ar četriem iepriekš uzskaitītajiem ekspluatācijas veidiem ir tā, ka autors min, cik grūti tos būtu veikt, jo bāzes Android kodolā trūkst funkciju. Ironiskā kārtā drošais RKP hipervizors nodrošināja visus rīkus, kas bija nepieciešami uzbrukumu veikšanai. Tas parāda, ka dažreiz labi domāta programmatūra rada vairāk problēmu nekā atrisina, un mums ir paveicies, ka mums ir cilvēki piemēram, Gal Benimini vēlas sasmērēt savas rokas un pārbaudīt, vai dokumentācija atbilst programmatūrai dara.

Lai gan šie varoņdarbi šķiet biedējoši un padara Knox skaņu ļoti ievainojamu, es vēlos visiem pārliecināt, ka šīs problēmas ir bijušas fiksēts janvāra atjauninājumā no Samsung. Turklāt šiem paņēmieniem ir nepieciešama ļoti dziļa izpratne par ARM procesoriem un programmēšanu, tāpēc šķēršļi ienākšanai šo ekspluatāciju izmantošanā ir astronomiski augsti.


Avots: Project Zero