Option ROM-sikkerhet i macOS
Merk: Option ROM-er støttes ikke på Macer med Apple-chip.
Option ROM-sikkerhet på Macer med Apple T2-sikkerhetsbrikke
Både Thunderbolt- og PCIe-enheter kan ha en «Option ROM (OROM)» fysisk knyttet til enheten. (Dette er vanligvis ikke en ekte ROM, men er i stedet en skrivbar brikke som lagrer firmware.) På UEFI-baserte systemer er den firmwaren vanligvis en UEFI-driver, som leses inn av UEFI-firmwaren og kjøres. Den kjørte koden skal initialisere og konfigurere maskinvaren den ble hentet fra, slik at maskinvaren kan brukes av resten av firmwaren. Denne funksjonaliteten kreves slik at spesialisert tredjepartsmaskinvare kan laste inn og fungere under de tidligste oppstartsfasene, for eksempel for å starte fra eksterne RAID-oppsett.
OROM-er er imidlertid generelt skrivbare og en eventuell angriper som overskriver OROM-en til en legitim ekstern enhet, kjører kode tidlig i oppstartsprosessen og kan manipulere kjøringsmiljøet og krenke integriteten til programvare som lastes senere. På samme måte, hvis angriperen introduserer sin egen ondsinnede enhet i systemet, kan de også kjøre ondsinnet kode.
I macOS 10.12.3 ble adferden til Macer som ble solgt etter 2011, endret til å ikke utføre OROM-er som standard på det tidspunktet Macen startet, med mindre en spesiell tastaturkombinasjon ble trykket ned. Denne tastaturkombinasjonen beskyttet mot at ondsinnede OROM-er utilsiktet ble introdusert i macOS-oppstartssekvensen. Standardadferden til Firmwarepassordverktøy ble også endret slik at når brukeren angir et firmwarepassord, kan ikke OROM-er utføres selv hvis tastaturkombinasjonen ble brukt. Dette beskyttet mot at en fysisk tilstedeværende angriper med hensikt introduserte en ondsinnet OROM. For brukere som fortsatt må kjøre OROM-er mens de har angitt et firmwarepassord, kan et ikke-standard-valg konfigureres ved hjelp av firmwarepasswd-kommandolinjeverktøyet i macOS.
Sikkerhet for OROM-sandkasse
I macOS 10.15 ble UEFI-firmware oppdatert for å inneholde en mekanisme for sandkasseteknologi for OROM-er og fjerne rettigheter fra dem. UEFI-firmware kjører vanligvis all kode, inkludert OROM-er, på det høyeste CPU-rettighetsnivået, som kalles ring 0, og bruker ett delt virtuelt minne-område for all kode og data. Ring 0 er rettighetsnivået der macOS-kjernen kjører, mens det lavere rettighetsnivået, ring 3, er der apper kjører. OROM-sandkassen fjernet rettigheter for OROM-er ved å benytte separasjon av virtuelt minne på samme måte som for kjernen, og deretter få OROM-ene til å kjøre i ring 3.
Videre begrenser sandkassen ytterligere både grensesnittene som OROM-ene kan kontakte (omtrent på samme måte som systemoppkallfiltrering i kjerner), og enhetstypen en OROM kan registreres som (omtrent på samme måte som godkjenning av apper.) Fordelen med denne designen er at ondsinnede OROM-er ikke lenger kan skrive direkte noe sted innen ring 0-minne. I stedet begrenses de til et svært smalt og veldefinert sandkassegrensesnitt. Dette begrensede grensesnittet reduserer angrepsflaten betydelig, og tvinger angripere til å først slippe ut av sandkassen og eskalere rettigheter.