Integrität des Betriebssystems
Bei der Entwicklung von Apple-Betriebssystemen steht die Sicherheit im Mittelpunkt. Das Design enthält einen Hardware-Vertrauensanker, der das sichere Starten ermöglicht, und einen sicheren Prozess für Softwareaktualisierungen. Apple-Betriebssysteme nutzen darüber hinaus speziell angefertigte Chip-basierte Hardwarefunktionen, die vor Exploits während des Systembetriebs schützen. Diese Funktionen schützen die Integrität von vertrauenswürdigem Code bei der Ausführung. Kurz gesagt tragen Apple-Betriebssysteme dazu bei, Angriffen, Missbrauchs- und Sabotagetechniken entgegenzuwirken – unabhängig davon, ob diese ihren Ursprung in Apps, im Internet oder in anderen Kanälen haben. Die hier aufgelisteten Schutzvorkehrungen sind auf Geräten mit unterstützten Apple-SoCs verfügbar – dazu gehören iOS, iPadOS, tvOS, watchOS und ab jetzt auch macOS auf Mac-Computern mit Apple Chips.
Funktion | A10 | A11, S3 | A12, A13, A14 S4–S9 | A15, A16, A17 | M1, M2, M3 |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
Siehe Anmerkung 1 unten. | |
Secure Page Table Monitor (SPTM) |
|
|
|
Siehe Anmerkung 2 unten. |
|
Anmerkung 1: Die PPL (Page Protection Layer) setzt voraus, dass die Plattform ausschließlich signierten und vertrauenswürdigen Code ausführt. Dieses Sicherheitsmodell ist in macOS nicht anwendbar.
Anmerkung 2: Der SPTM (Secure Page Table Monitor) wird beim A15, A16 und A17 unterstützt und ersetzt PPL auf unterstützten Plattformen.
Kernel-Integritätsschutz
Nachdem die Kernel des Betriebssystems die Initialisierung abgeschlossen haben, wird der Kernel-Integritätsschutz (Kernel Integrity Protection, KIP) aktiviert, um Änderungen an Kernel und Treibercode zu verhindern. Der Speichercontroller stellt eine geschützte Region im physischen Speicher bereit, die von iBoot verwendet wird, um den Kernel und Kernel-Erweiterungen zu laden. Nach dem Startvorgang blockiert der Speichercontroller Schreibzugriffe auf die geschützte Region im physischen Speicher. Die MMU (Memory Management Unit) des Anwendungsprozessors wird so konfiguriert, dass das Mapping von privilegiertem Code vom physischen Speicher außerhalb der geschützten Speicherregion verhindert wird und dass schreibbare Mappings des physischen Speichers innerhalb der Kernel-Speicherregion verhindert werden.
Die zur Aktivierung des KIP verwendete Hardware wird nach der Beendigung des Startvorgangs gesperrt, um eine Neukonfiguration zu verhindern.
Schnelle Berechtigungseinschränkungen
Mit dem Apple A11 Bionic S3 SoC wurde eine neue Hardware-Primitive eingeführt. Diese Primitive (Fast Permission Restrictions) umfasst ein CPU-Register für das schnelle Einschränken von Berechtigungen pro Thread. Dank dieser schnellen Berechtigungseinschränkung (auch als APRR-Register bezeichnet) sind unterstützte Betriebssysteme in der Lage, Ausführungsberechtigungen aus dem Arbeitsspeicher zu entfernen – ohne den Mehraufwand eines Systemaufrufs und eines Durchlaufs oder Leerens der Seitentabelle. Dies bietet eine zusätzliche Abwehrebene gegen Angriffe aus dem Internet, insbesondere gegenüber Aktionen, die JIT-kompiliert (Just-in-time) sind, da Speicher nicht effektiv genutzt werden kann, während er gleichzeitig les- und beschreibbar ist.
Integritätsschutz des System-Coprozessors
Die Coprozessor-Firmware übernimmt viele kritische Systemaufgaben – zum Beispiel die Secure Enclave, den Bildsensorprozessor und den Bewegungscoprozessor. Aus diesem Grund kommt ihrer Sicherheit eine Schlüsselrolle bei der Sicherheit des Gesamtsystems zu. Apple verwendet einen Mechanismus namens System-Coprozessor-Integritätsschutz (System Coprocessor Integrity Protection, SCIP), um Modifikationen der Coprozessor-Firmware zu verhindern.
SCIP funktioniert auf ganz ähnliche Weise wie der Kernel-Integritätsschutz (KIP): Beim Starten lädt iBoot die Firmware jedes Coprozessors in eine geschützte Speicherregion, die eigens dafür reserviert und von der KIP-Region abgetrennt ist. iBoot konfiguriert die Speichereinheit jedes Prozessors, um Folgendes zu verhindern:
Ausführbare Mappings außerhalb des entsprechenden Teils der geschützten Speicherregion
Ausführbare Mappings innerhalb des entsprechenden Teils der geschützten Speicherregion
Beim Starten wird zum Konfigurieren der SCIP für die Secure Enclave das Betriebssystem der Secure Enclave verwendet. Nachdem der Startvorgang abgeschlossen wurde, wird die Hardware gesperrt, die zum Aktivieren von SCIP verwendet wurde. Dadurch soll eine Neukonfiguration verhindert werden.
PACs (Pointer Authentication Codes)
Pointer Authentication Codes (PACs) werden verwendet, um zu verhindern, dass Fehler ausgenutzt werden können, die den Speicher modifizieren. Systemsoftware und integrierte Apps verwenden PAC, um Änderungen an Funktionszeigern und Rückgabeadressen (Codezeigern) zu verhindern. PAC verwendet fünf geheime 128-Bit-Werte, um Kernel-Anweisungen und Daten zu signieren, und jeder Benutzerbereich verfügt über seine eigenen B-Schlüssel. Objekte werden wie folgt mit Salt- und Signaturdaten versehen.
Objekt | Schlüssel | Salt |
|---|---|---|
Funktionsrückgabeadresse | IB | Speicheradresse |
Funktionszeiger | IA | 0 |
Funktion für Blockaufrufe | IA | Speicheradresse |
Objective-C-Methodencache | IB | Speicheradresse + Klasse + Selektor |
C++ V-Tabelleneinträge | IA | Speicheradresse + Hash (beschädigter Methodenname) |
Berechnetes Goto-Etikett | IA | Hash (Funktionsname) |
Kernel-Thread-Status | GA | • |
Benutzer-Thread-Statusregister | IA | Speicheradresse |
C++ V-Tabellenzeiger | DA | 0 |
Der Signaturwert wird in nicht benutzten Füll-Bits oben im 64-Bit-Zeiger gespeichert. Die Signatur wird vor der Verwendung überprüft und die Füllung wird wiederhergestellt, um eine funktionierende Speicheradresse sicherzustellen. Ein Scheitern der Überprüfung führt zum Abbruch. Diese Überprüfung erschwert viele Angriffe – zum Beispiel einen ROP-Angriff (Return Oriented Programming), der versucht, durch die Manipulation der auf dem Stack abgelegten Funktionsrückgabeadressen das Gerät zu verleiten, vorhandenen Code in böswilliger Absicht auszuführen.
Page Protection Layer (PPL)
Bei iOS, iPadOS und watchOS sorgt PPL (Page Protection Layer) für den Schutz von Code im Benutzerbereich (User Space), nachdem die Überprüfung der Code-Signatur abgeschlossen wurde. PPL baut auf Kernel-Integritätsschutz und schnellen Berechtigungseinschränkungen auf, um die Überschreibungen von Berechtigungen für Seitentabellen sorgfältig zu verwalten und so sicherzustellen, dass nur die PPL geschützten Seiten, die Benutzercode und Seitentabellen enthalten, ändern kann. Das System reduziert die Angriffsfläche drastisch, indem es das Erzwingen der systemweiten Codeintegrität unterstützt, selbst wenn der Kernel beeinträchtigt wurde. macOS bietet diesen Schutz nicht an, da PPL nur auf Systemen zum Einsatz kommt, auf denen jeglicher ausgeführter Code signiert sein muss.
Secure Page Table Monitor (SPTM) und Trusted Execution Monitor (TXM)
Secure Page Table Monitor (SPTM) und Trusted Execution Monitor (TXM) arbeiten zusammen, um Seitentabellen für Benutzer- und Kernelprozesse selbst dann vor Modifikationen zu schützen, wenn Angreifer Schreibvorgänge im Kernel ausführen und Kontrollfluss-Schutzfunktionen umgehen können. SPTM erreicht dies durch Nutzung einer höheren Berechtigungsstufe als der Kernel und setzt den mit geringeren Berechtigungen ausgestatteten TXM zur tatsächlichen Durchsetzung der Richtlinien für die Codeausführung ein. Dieses System ist so konzipiert, dass aufgrund der separaten Berechtigungen und der gegenseitigen Vertrauensstellung eine Kompromittierung von TXM nicht automatisch eine Umgehung von SPTM ermöglicht. Unter A15, A16 und A17 SOCs, SPTM (in Kombination mit TXM) ist SPTM als Ersatz für das PPL konzipiert. Dabei wurde eine kleinere Angriffsfläche entwickelt, die nicht auf das Vertrauen des Kernels angewiesen ist, selbst während des frühen Startvorgangs. SPTM nutzt außerdem neue Silicon Primitives, die eine Weiterentwicklung der von PPL genutzten schnellen Berechtigungseinschränkungen darstellen.