Operativsystemintegritet
Apples operativsystem er utviklet med fokus på sikkerhet. Det inkluderer en maskinvarebasert «root of trust» – som brukes for å sørge for sikker oppstart – og en sikker prosess for programvareoppdateringer som er både rask og trygg. Apples operativsystemer bruker også spesialbygde, silisiumbaserte maskinvarefunksjoner for å bidra til å forhindre utnyttelse når systemet kjører. Disse funksjonene ved kjøring beskytter integriteten til godkjent kode når den kjøres. Kort fortalt bidrar Apples operativsystem til å redusere angreps- og utnyttelsesteknikker – uansett om de stammer fra en ondsinnet app, fra internett eller gjennom en annen kanal. Beskyttelsene som er oppført her, er tilgjengelige på enheter med støttede Apple-designede SoC-er, inkludert iOS, iPadOS, tvOS og watchOS, og nå også macOS på Macer med Apple-chip.
Funksjon | A10 | A11, S3 | A12, A13, A14 S4–S9 | A15, A16, A17 | M1, M2, M3 |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
Se note 1 nedenfor. | |
|
|
|
Se note 2 nedenfor. |
|
Note 1: PPL (Page Protection Layer) krever at plattformen kun kjører signert og godkjent kode. Dette er en sikkerhetsmodell som ikke er gjeldende for macOS.
Note 2: Secure Page Table Monitor (SPTM) støttes på A15, A16 og A17 og erstatter Page Protection Layer på støttede plattformer.
Kernel Integrity Protection
Etter at operativsystemkjernen fullfører initialisering, aktiveres Kernel Integrity Protection (KIP) for å bidra til å hindre modifisering av kjerne- og driverkode. Minnekontrolleren har et beskyttet område i fysisk minne der iBoot laster inn kjernen og kjerneutvidelser. Når oppstart er fullført, hindrer minnekontrolleren skriving til det beskyttede minneområdet. Applikasjonsprosessorens minneadministreringsenhet (MMU) er konfigurert for å bidra til å forhindre tilordning av privilegert kode fra fysisk minne utenfor det beskyttede minneområdet, og for å bidra til å forhindre skrivbare tilordninger av fysisk minne innen kjerneminneområdet.
For å hindre rekonfigurering, låses maskinvaren som brukes til å aktivere KIP etter at oppstartsprosessen fullføres.
Raske rettighetsrestriksjoner
Fra og med Apple A11 Bionic og S3-SoC-er ble nye maskinvaregrunnelementer introdusert. Disse grunnelementene (raske rettighetsrestriksjoner) inkluderer et CPU-register som raskt begrenser rettigheter etter tråd. Med raske rettighetsrestriksjoner (også kjent som APRR), kan støttede operativsystemer fjerne kjørerettigheter fra minnet uten å ta belastningen som oppstår ved et systemkall og en sidetabellgjennomgang/rydding. Disse registrene reduserer risikoen for angrep fra internett ytterligere, spesielt kode som er kompilert ved kjøring (JIT-kompilert – Just-in-time), siden minnet faktisk ikke er kjørbart samtidig som det kan leses og skrives.
System Coprocessor Integrity Protection
Koprosessorfirmware håndterer mange kritiske systemoppgaver, for eksempel Secure Enclave, bildesensorprosessoren og koprosessoren for bevegelse. Dennes sikkerhet er derfor en viktig del av sikkerheten til hele systemet. For å hindre modifisering av koprosessorfirmwaren bruker Apple en mekanisme som kalles System Coprocessor Integrity Protection (SCIP).
SCIP fungerer på mange måter som Kernel Integrity Protection (KIP). Ved oppstart laster iBoot hver koprosessors firmware inn i et beskyttet minneområde, et som er reservert og separat fra KIP-området. iBoot konfigurerer hver koprosessors minneenhet for å bidra til å forhindre:
utførbare tilordninger utenfor sin del av det beskyttede minneområdet
skrivbare tilordninger innenfor sin del av det beskyttede minneområdet
Også ved oppstart, for å konfigurere SCIP for Secure Enclave, brukes Secure Enclave-operativsystemet. Etter at oppstartsprosessen er fullført, låses maskinvaren som brukes til aktivere SCIP. Dette er utviklet for å hindre rekonfigurering.
Pointer Authentication Codes
Pointer Authentication Codes (PAC-er) brukes til å beskytte mot utnyttelse av feil i minnet. Systemprogramvare og innebygde apper bruker PAC til å bidra til å forhindre modifisering av funksjonspekere og returadresser (kodepekere). PAC bruker fem hemmelige 128-bit-verdier til å signere kjerneinstruksjoner og data, og hver brukerområdeprosess har sine egne B-nøkler. Objekter saltes og signeres som vist under.
Objekt | Nøkkel | Salt |
|---|---|---|
Funksjonsreturadresse | IB | Lagringsadresse |
Funksjonspekere | IA | 0 |
Blokkoppkallsfunksjon | IA | Lagringsadresse |
Objective-C-metodebuffer | IB | Lagringsadresse + Klasse + Velger |
C++ V-tabelloppføringer | IA | Lagringsadresse + hash (mangled method name) |
Beregnet Goto-etikett | IA | Hash (funksjonsnavn) |
Kjernetrådtilstand | GA | • |
Brukers trådtilstandsregistre | IA | Lagringsadresse |
C++ V-tabellpekere | DA | 0 |
Signaturverdien lagres i de ubrukte utfyllings-bit-ene øverst i 64-bitspekeren. Signaturen verifiseres før bruk, og utfyllingen gjenopprettes for å bidra til å sikre en fungerende pekeradresse. Hvis verifiseringen mislykkes, avbrytes det. Denne verifiseringen vanskeliggjør mange angrep, for eksempel Return-Oriented Programming-angrep (ROP), som forsøker å lure enheten til å kjøre eksisterende kode på en ondsinnet måte ved å manipulere funksjonsreturadresser lagret på stabelen.
Page Protection Layer
Page Protection Layer (PPL) i iOS, iPadOS og watchOS er utviklet for å hindre brukerområdekode i å bli modifisert etter at kodesignaturverifisering er fullført. PPL bygger på KIP og raske rettighetsrestriksjoner og styrer sidetabellrettighetsoverstyringene for å sikre at kun PPL kan endre beskyttede sider som inneholder brukerkode og sidetabeller. Systemet tilbyr en enorm reduksjon i angrepsflate ved å støtte systemomfattende kodeintegritetshåndheving, selv i møte med en kompromittert kjerne. Denne beskyttelsen tilbys ikke på macOS fordi PPL kun gjelder på systemer der all kjørt kode må signeres.
Secure Page Table Monitor og Trusted Execution Monitor
Secure Page Table Monitor (SPTM) og Trusted Execution Monitor (TXM) er utviklet for å samarbeide for å bidra til å beskytte sidetabeller for både bruker- og kjerneprosesser mot endringer, selv om angripere har klart å få tilgang til å skrive til kjernen og kan forbigå kontrollflytbeskyttelser. SPTM gjør dette ved å bruke høyere rettighetsnivå enn kjernen, og ved å bruke TXM, som har lavere rettighetsnivå, til å håndheve reglene som styrer kjøring av kode. Systemet er designet slik at kompromittering av TMX ikke automatisk oversettes til en forbigåing av SPTM, siden rettighetsnivåene holdes adskilt og godkjenningen styres mellom dem. I A15, A16 og A17 SOC-er erstatter SPTM (kombinert med TXM) PPL for å skape en mindre angrepsflate som ikke er avhengig av godkjenning fra kjernen, selv under tidlig oppstart. SPTM er også avhengig av nye grunnelementer fra chipen, som er en videreutvikling av de raske rettighetsrestriksjonene som PPL bruker.