I det siste Project Zero-blogginnlegget har teamet oppdaget en måte å omgå Samsungs sanntids kjernebeskyttelse, kalt Knox Hypervisor.
Googles Project Zero-team har bekreftet en rekke utnyttelser som gjør at Samsungs telefoner som kjører den antatt sikre Samsung Knox-sikkerhetspakken, kan bli angrepet. Bloggen bemerker at alle sårbarheter er overført til Samsung som faktisk har gitt ut rettelser for dem i en programvareoppdatering fra januar.
Bakgrunn
Som en del av Samsung Knox sikkerhetsprogramvaresuite introdusert av Samsung, er det et stykke programvare som sitter mellom Android-applikasjoner og kjernen kalt en Hypervisor. Dette kan brukes som et ekstra lag for å sikre Android-enheter ytterligere. Samsung Knox Hypervisor heter "Sanntids kjernebeskyttelse" eller RKP for kort, som jeg vil referere til i resten av denne artikkelen.
Kjernen ligger under RKP i Android-programvarestabelen, og applikasjonene som kjører på enheten sitter øverst. Ideen bak RKP er å gi et ekstra lag med sikkerhet for enheten ettersom alle forespørsler (minne og andre ressurser) fremsatt av applikasjoner til kjernen må gå gjennom Knox først, som prøver å oppdage om en applikasjon gjør noe burde ikke. RKP gir også sikkerhet gjennom uklarhet med et ekstra lag for å skjule sensitiv informasjon en applikasjon kan bruke for å kompromittere enheten.
Blogginnlegget går ganske dypt inn i hvordan Android-minne, RKP og operativsystemer generelt fungerer, så jeg har komprimert og forenklet det for å gi en rask oversikt over hva som ble oppdaget. Jeg oppfordrer deg imidlertid til å lese hele artikkelen hvis du har tid, siden den er veldig opplysende.
Utnyttelse nr. 1:
KASLR eller Kernel Address Space Layout Randomisering er prosessen med å endre plasseringen av kjernekoden i minnet med et tilfeldig beløp ved oppstart. Hver gang enheten startes opp, lastes kjernen inn i et annet adresseområde (område i minnet). Ideen er å gjøre det vanskeligere å finne hvor kjernekoden er plassert for å angripe den fordi etter hver oppstart "skifter" kjernekoden seg med en tilfeldig mengde i minnet. Dette høres ut som et flott skritt for å forhindre potensielle angripere, men nylig forskning har vist at du faktisk kan overvinne dette uten å kreve en programvarefeil eller sårbarhet, da KASLR faktisk er veldig vanskelig å implementere på en robust måte mot lokale angripere.
Når det gjelder RKP-programvaren, er muligheten til å omgå KASLR faktisk enklere enn forskningen referert til ovenfor. Alle android-enheters minne refereres av pekere og for å beskytte enhetene mot angrep, når android-enheter skrives ut eller sendes ut (enten til skjerm eller å arkivere for logger eller feilsøking), er pekerreferansene anonymisert, - noe som gjør det umulig å finne ut hvor pekeren faktisk peker til når du leser produksjon.
Tenk på minnepekere som et gateskilt som peker på en plassering, og tenk på anonymisering som å gjøre det uskarpt. På samme måte som TV, gjøres anonymisering etter filmingen, Android bruker også denne anonymiseringen ved utdata og bare hvis anonymisering er riktig konfigurert, og forfatteren sier at hver enhet [han] møtte har hatt pekeranonymisering riktig konfigurert. Dette kan høres ut som det er veldig vanskelig å bryte, men alt du trenger å gjøre er å finne en enkelt peker (tenk gateskilt) som ikke var anonymisert (uskarpt) av kjerneutvikleren (pass på at dette ikke er din gjennomsnittlige Android-apputvikler) når pekeren skrives til loggene eller et annet sted, f.eks. skjerm eller en fil.
Så hvis du kan finne en peker som ikke var anonymisert, kan du beregne kjernens tilfeldige adresseskift som forskjellen mellom de to. Interessant nok kunne ikke forfatteren finne en utnyttbar peker i kjernen, men fant den inne i RPK der utviklere glemte å anonymisere en peker i feilsøkings(logging)-utgangen, som kom i form av en skrivefeil. For å anonymisere pekerne i Android må du bruke en spesiell kode, og det viser seg at RPK-utviklerne feilaktig brukte en liten "k" i stedet for en stor "K". Derfor var det relativt enkelt å finne ut den tilfeldige skiftmengden til kjernekoden og angripe den.
Utnyttelse #2:
Den neste utnyttelsen er litt mer kompleks: Samsung Knox beskytter enheten din ved å bruke et sett med regler på enhetens minne for å stoppe skadelig kode. Reglene er som følger:
- Alle sider (kode i minnet), med unntak av kjernens kode, er merket som "Privileged Execute Never" (som betyr at kode her aldri kan kjøres)
- Kjernedatasider (data som brukes av programmet i minnet) er aldri merket som kjørbare (så koden her kan aldri kjøres)
- Kjernekodesider (kode i minnet) er aldri merket som skrivbare (så ingen ondsinnet kode kan endre det)
- Alle kjernesider er merket som skrivebeskyttet i trinn 2-oversettelsestabellen (tabellen som sitter mellom applikasjonen og kjernen for ytterligere å forhindre at applikasjoner vet om ekte minneplasseringer)
- Alle minneoversettelsesoppføringer er merket som skrivebeskyttet for programmer.
Vi vil fokusere på regel 3 da det er her forfatteren fant et problem med implementeringen av reglene ovenfor. RPK markerer faktisk minnet for kjernen som skrivebeskyttet, men som en forglemmelse for KASL ble det oppdaget et hull som førte til skrive kode inn i den angivelig "skrivebeskyttede" delen. For å tilsløre plasseringen av kjernen ved oppstartstid blir minne tildelt kjernen, men denne minnemengden er mye større enn kjernens tekstsegment. Ved å tildele en større mengde minne gjør det det mye vanskeligere å finne den faktiske kjernekoden som kan være hvor som helst, og som vi så ovenfor flyttes den tilfeldig ved hver oppstart av enheten.
Forfatteren var i stand til å bekrefte at minnet brukt av kjernen faktisk var merket som "skrivebeskyttet", men resten av den store mengden minne som ble brukt til å skjule kjernen var ikke merket som "skrivebeskyttet". Dette er fordi RKP bare beskytter regionen som inneholder kjernens tekst etter å ha brukt KASLR-lysbildet.
Utnyttelse #3
I den tredje utnyttelsen var forfatteren i stand til å få tilgang til et annet minneområde som også burde være begrenset til skrivebeskyttet. RKP beskytter minne og bruker en Hypervisor konfigurasjonsregister (HCR) for å kontrollere nøkkelkjerneoperasjoner. Poenget med HCR er å la gyldige og ekte kjerneoperasjoner få tilgang til registrene og blokkere ondsinnede angrep. Den gjør dette ved å sjekke anropene til registrene som styrer virtualiseringsfunksjonene. HCR er konfigurert til å blokkere spesifikke operasjoner som normalt vil bli håndtert, slik at RKP kan velge om den skal tillate eller avvise en forespørsel.
I denne utnyttelsen var HCR-kontrollen ikke dekker to registre som viste seg å være veldig viktig. Forfatteren gravde dypt inn i ARM Reference manualen og oppdaget at det første registeret tillot ham i utgangspunktet å slå av RKP for applikasjoner. den "Systemkontrollregister for EL1 (SCTLR_EL1) gir toppnivåkontroll over systemet, inkludert minnesystemet." I en perfekt verden ville applikasjonen bruke minne som ble kartlagt via RKP slik at RKP kunne kontrollere hva applikasjonen kunne få tilgang til. Men å slå av dette registeret tillot RKP skal deaktiveres ved å effektivt returnere enheten til hvordan den kjørte før RKP ble installert - noe som betyr at enheten er kartlagt til fysisk minne uten den ekstra sikkerheten som tilbys av RKP. Det betydde igjen at forfatteren kunne lese og skrive til et minne som opprinnelig og korrekt ble blokkert av RKP-programvaren.
Det andre registeret som ble savnet hadde en mer subtil effekt, men til slutt like ødeleggende for sikkerheten. De Oversettelseskontrollregister for EL1 (TCR_EL1) register er direkte knyttet til mengden minne som en applikasjon arbeider med kalt en side. RKP er hardkodet til en sidestørrelse på 4kb fordi AARCH64 Linux-kjerner (som Android) bruker en oversettelsesstørrelse på 4KB. Registeret det gjelder (TCR_EL1) setter ARM-brikkesettene til størrelsen på minnet som skal returneres. Det viser seg at dette registeret er ikke beskyttet av HCR og derfor kan en angriper endre det ettersom forfatteren endret det til en sidestørrelse på 64 kb.
Hva dette betyr er at når forespørselen oppfylles av RKP, er den faktiske mengden tilgjengelig minne nå 64kb i stedet for 4kb. Årsaken er at ARM-brikkesettet fortsatt kontrollerer sidestørrelsen, og det ble satt til 64kb av utnyttelsen. Siden RKP beskytter minnet fra å bli skrevet til, som en del av reglene oppført i utnyttelse #2, er minnet fortsatt faktisk beskyttet. Men her er haken - siden RKP er hardkodet til 4kb endres den ikke til en sidestørrelse på 64kb når registeret ble oppdatert, så bare de første 4 kb med minne er beskyttet lar angriperen gjøre hva han vil med de resterende 60kb.
Utnyttelse #4
Den siste utnyttelsen forfatteren viser er å referere til minnet der RKP-programvaren er, slik at angriperen kan angripe selve RKP-programvaren. Et triks for å stoppe denne typen angrep som også Linux-kjerner bruker, er å fjerne kartleggingen av programmet ditt fra adresserommet i det virtuelle minnet slik at ingen applikasjoner kan angripe det fordi de ikke kan referere til det.
Husk at minne handler om pekere og tabeller som kartlegger fysisk minne til virtuelt minne. I henhold til det normale forsvaret i denne typen angrep, kartlegger RKP seg selv slik at det ikke kan angripes. Men der kjernen ikke gir slike evner, tillater RKP at et stykke minne kartlegges og merkes som Les/skriv. Den eneste kontrollen er at det ikke er den underliggende kjernen i seg selv, da RKP ikke kontrollerer om adressene som blir bedt om å kartlegges er området der RKP selv ligger i minnet. I utgangspunktet RKP lar seg kartlegge på nytt tilbake til adresseområdet som applikasjoner har tilgang til og som en side påvirker minnet merkes automatisk som Les/skriv så en angriper kan nå bruke minnet slik den vil.
Konklusjon
Et av de største problemene med de fire utnyttelsene som er oppført ovenfor, er at forfatteren nevner hvor vanskelig disse ville være å utføre på grunn av mangelen på funksjoner i Android-kjernen. Ironisk nok ga den sikre RKP Hypervisor alle verktøyene som var nødvendige for å utføre angrepene. Det viser seg at programvare med god intensjoner forårsaker flere problemer enn den løser, og vi er heldige som har folk som Gal Beniamini villig til å skitne på hendene og teste at dokumentasjonen stemmer overens med programvaren gjør.
Selv om disse utnyttelsene virker skumle og får Knox til å høres veldig sårbare ut, vil jeg gjerne forsikre alle om at disse problemene har vært fikset i januaroppdateringen fra Samsung. Videre krever disse utnyttelsene en veldig dyp forståelse av ARM-prosessorer og programmering, så adgangsbarrieren for å bruke disse utnyttelsene er astronomisk høy.
Kilde: Project Zero