MacOS ist bekannt für seine robuste Sicherheit, doch festinstallierte Dienste, die unter hohen Privilegien laufen, präsentieren potenzielle Angriffsflächen für enthusiastische Sicherheitsforscher. Eines der innovativsten Methoden, um solche Schwachstellen aufzuspüren, ist das sogenannte Fuzzing — eine Technik, bei der zielgerichtet und automatisiert große Mengen an Daten an Programme gesendet werden, um dessen Verhalten zu testen und Fehler aufzudecken. Besonders spannend ist die Anwendung dieser Methode auf CoreAudio, einen zentralen Teil des MacOS-Betriebssystems, der für die Steuerung von Audiohardware verantwortlich ist. Im Fokus steht dabei die Verwendung von Mach Messages, die auf niedrigster Ebene der Interprozesskommunikation (IPC) in MacOS stattfinden. Die Herausforderung bei der Sicherheit von MacOS liegt darin, dass viele systemeigene Dienste durch IPC laufen und somit von unprivilegierten Prozessen Nachrichten empfangen können.
Diese Kommunikationswege sind potenzielle Einfallstore für Angreifer, die sie nutzen, um die Systemgrenzen zu überwinden – sogenannte Sandbox-Escapes. Eine wichtige Rolle spielt dabei der Mechanismus der Mach Nachrichten. Mach selbst verwaltet Nachrichten in Kernel-gesteuerten Warteschlangen, die über sogenannte Mach Ports adressiert werden. Ein Prozess, der das Empfängerrecht für einen Port besitzt, kann Nachrichten aus dieser Warteschlange entnehmen, während Prozesse mit Senderecht Nachrichten verschicken können. Diese fein granulierte Rechteverwaltung macht Mach Messages einerseits mächtig und andererseits komplex und anfällig für Fehlkonfigurationen oder Fehler in der Bearbeitung.
Beim Fuzzing von CoreAudio ist es entscheidend, zunächst die richtigen Angriffspunkte zu identifizieren. Der CoreAudio-Daemon, insbesondere dessen Mach Service mit der Bezeichnung com.apple.audio.audiohald, wurde aufgrund seiner Komplexität, der Erreichbarkeit durch verschiedene Anwendungen wie Safari und seiner umfangreichen Nachrichtenhandler als Ziel ausgewählt.
CoreAudio stellt eine Schnittstelle namens Hardware Abstraction Layer (HAL) bereit, die Audiohardware und zugehörige Einstellungen kontrolliert. Jeder Client, der diese interagieren möchte, muss sich zunächst registrieren, etwa über die Mach Message _XSystem_Open. Die Mach Interface Generator (MIG)-Technologie vereinfachte das Auffinden der kritischen Nachrichtenschnittstellen. MIG hilft, RPC-Clients und Server durch Abstraktion der Mach Nachrichten einfacher zu entwickeln. Beim Reverse Engineering ergab sich, dass viele Nachrichtentypen über eine zentrale Struktur namens Subsystem abgewickelt werden.
Damit wurde der zentrale Handler identifiziert, der eingehende Mach Messages entgegennimmt und anhand der Nachrichten-IDs an entsprechende Funktionen weiterleitet. Ein zentrales Element eines erfolgreichen Fuzzing-Frameworks ist der Fuzzing Harness, ein Programm, das Eingaben (bzw. Nachrichten) synthetisch generiert und diese der Zielanwendung direkt übergibt. Angesichts von Kern-Hardware-Validierungen war die Entscheidung zugunsten eines Direct Harness gefallen, das die Mach Message Handler innerhalb eines Prozesses lädt und ansteuert, um Probleme mit Performance und Code Coverage zu umgehen. Dies ermöglichte, ohne die schwerfällige Kernel-Interaktion, eine präzisere Analyse und effizientere Instrumentierung.
Ein practischer Aspekt war die Beschaffung eines guten Startkorpus an legitimen Mach Nachrichten, um den Fuzzer „intelligent“ starten zu lassen. Hierbei kamen Breakpoints und Debugging zum Einsatz, um reale Nachrichtendaten zu extrahieren. Ein Beispiel hierfür war das Audiomidi-Setup, mit dem Geräte verändert wurden, sodass der Datenverkehr nachvollziehbar wurde. So konnte der Fuzzer auf bestehenden Mustern aufbauen und verlor nicht unnötig Zeit mit sinnlosen Eingaben. Der iterative Prozess des Harness-Baus umfasste verschiedene Stufen, angefangen von der Initialisierung des HAL Systems, um konsistente Zustände herzustellen, über das sogenannte API Call Chaining, bei dem mehrere zusammenhängende Nachrichten in einer Serie generiert werden, um Zustandsabhängigkeiten abzubilden, bis hin zum gezielten Mocking von nicht relevanten oder problematischen Funktionen, die den Fuzzing-Prozess sonst abbremsen würden.
Die Berücksichtigung solcher Aspekte erhöhte die Codeabdeckung des Fuzzers deutlich und ermöglichte das Auftreten von relevanten Abstürzen, die sonst ausbleiben würden. Eine der Kernherausforderungen beim Fuzzing solcher komplexer Systeme ist die Einhaltung syntaktischer und semantischer Vorgaben der Nachrichten. Zum Beispiel musste die Struktur und Länge von Mach Nachrichten einigen strikten Voraussetzungen genügen, um überhaupt als gültig behandelt zu werden. Ohne das Wissen über diese Anforderungen wäre der Fuzzer kaum in der Lage gewesen, tiefere Pfade auszulösen. Besonders bei Out-of-line (OOL) Daten in Mach Messages, die Speicherreferenzen enthalten, zeigte sich wie wichtig es ist, gültigen und kontrollierbaren Speicher bereitzustellen, um die Zielprozesse nicht durch falsche Speichervalidierung abstürzen zu lassen.
Während der Fuzzing-Phase fanden sich zahlreiche Abstürze, die zunächst kaum auf Sicherheitslücken hindeuteten, wie z.B. NULL-Dereferenzen. Doch die genaue Analyse zeigte, dass manche Handler in CoreAudio Objekttypen nicht ausreichend prüfen. Speziell bei der Verarbeitung von HALS_Objecten gab es eine kritische Type Confusion: Ein Objekt wurde fälschlicherweise als ein bestimmter Typ behandelt, ohne dessen Identität vorher zu verifizieren.
Dies führte dazu, dass Funktionszeiger aus einer falschen Tabelle ausgelesen und aufgerufen werden konnten – ein klassischer und äußerst gefährlicher Fehler, da dadurch die Kontrolle über den Programmfluss erlangt werden kann. Das genaue Verständnis der Abläufe offenbarte, dass einige Nachrichtenhandler auf das Objekt mit Type ’ioct’ vertrauten, ohne abzusichern, dass dieses wirklich vorlag. Das führte im Falle abweichender oder gefälschter Objekte zu Speicherzugriffen außerhalb erlaubter Bereiche oder zur Ausführung von Code an unbekannten Speicheradressen. Solche Schwachstellen ermöglichen Angreifern, Berechtigungen zu eskalieren oder sogar Schadcode beliebiger Natur auszuführen – ein klassischer Sandbox-Escape. Die Sicherheit ist umso bedenklicher, da der CoreAudio-Daemon mit erhöhten Rechten angesiedelt ist, eine mögliche Übernahme könnte also gravierend sein.
Die Analyse zeigte außerdem, dass Apple einige Nachrichtenhandler zwar ordentlich prüfte, aber inkonsistente Prüfroutinen im System verbleiben, was die Angriffsfläche weiter vergrößert. Der Nachweis, dass dieser Fehler über das normale mach_msg API ausnutzbar war, bestätigte die potentielle Exploitierbarkeit. Dadurch konnte ein Proof-of-Concept entwickelt werden, das den Fehler realistisch und reproduzierbar auslöst. Die Erkenntnisse sind zudem wichtig, weil Apple ab macOS Big Sur durch die dyld Shared Cache Architektur viele Binärdateien in diesem Cache lagert, was eine klassische Inspektion erschwert und somit Innovationen im Bereich Reverse Engineering und dynamischer Analyse unverzichtbar macht. Die Reaktion seitens Apple erfolgte relativ zügig nach Meldung durch Sicherheitsforscher.
Der Fix bestand darin, eine Typprüfung in die kritischen Mach Nachrichtem-Handler zu integrieren, die vor der Nutzung des Objekts dessen Typ validiert, um die Verwechslung zu verhindern. Die Beseitigung des Fehlers wurde unter der CVE-Nummer 2024-54529 katalogisiert und in macOS Versionen Sequoia 15.2, Sonoma 14.7.2 sowie Ventura 13.
7.2 veröffentlicht. Abschließend zeigt dieser Forschungs- und Entwicklungsprozess, wie wichtig eine Kombination aus automatisiertem Fuzzing, manuellem Reverse Engineering und dynamischer Instrumentierung ist. Die Methode des sogenannten knowledge-driven Fuzzing, welche automatisierte Erkennung mit gezielter manueller Analyse verknüpft, eröffnete den Forschern tiefe Einblicke in eine bisher undurchsichtige Systemkomponente. Dieses Vorgehen macht MacOS-Sicherheitsforschung greifbar und bietet eine Blaupause für zukünftige Analyse- und Angriffspunkte abseits der klassischen Nutzerschnittstellen.
