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.
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.
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.
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
Objective-C-Methodencache
Speicheradresse + Klasse + Selektor
C++ V-Tabelleneinträge
Speicheradresse + Hash (beschädigter Methodenname)
Berechnetes Goto-Etikett
Hash (Funktionsname)
Kernel-Thread-Status
GA
•
Benutzer-Thread-Statusregister
C++ V-Tabellenzeiger
DA
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.
Bei iOS, iPadOS, watchOS und visionOS 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) auf iOS, iPadOS, macOS und visionOS 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. Auf dem A15 (oder neuer) sowie dem M2 oder neueren SOCs, ist SPTM (in Kombination mit TXM) 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 neue Silicon Primitives, die eine Weiterentwicklung der von PPL genutzten schnellen Berechtigungseinschränkungen darstellen und nur für die oben in der Tabelle aufgeführten Prozessoren verfügbar sind.