Kann man den Berechtigungs-Pop-ups von macOS vertrauen?

• CVE-2025-31250 ist eine Schwachstelle, die die TCC-Zustimmungs-Pop-ups für Berechtigungen unter macOS schwer vertrauenswürdig machte: Die auf dem Bildschirm angezeigte App und die App, die tatsächlich die Berechtigung erhielt, konnten voneinander abweichen
• Das Problem lag in der Verarbeitung von TCCAccessRequestIndirect in tccd; target_path wurde für den im Pop-up angezeigten App-Namen verwendet, target_identifier für den Identifier der App, die tatsächlich die Berechtigung erhalten sollte
• Anders als bei früheren Umgehungen waren weder Fake-Apps, Dock-Verknüpfungen noch das gezielte Herbeiführen eines Nutzerklicks nötig; wenn der Nutzer im gespooften Pop-up auf Allow klickte, konnte der Angriff gelingen
• Apple hat die Schwachstelle in macOS Sequoia 15.5 gepatcht, bestätigte aber, dass Ventura 13.7.6 und Sonoma 14.7.6, die am selben Tag erschienen, nicht gepatcht wurden und dass es keine Patch-Pläne für ältere Versionen gibt
• Angreifer können versuchen, in dem Moment, in dem Apps wie FaceTime, Voice Memos oder System Settings geöffnet werden, ein gespooftes Berechtigungs-Pop-up anzuzeigen, sodass Nutzer Gefahr laufen, das tatsächliche Ziel der Berechtigungsvergabe falsch einzuschätzen

---

Kernverhalten von CVE-2025-31250

• CVE-2025-31250 ist eine Schwachstelle, durch die sich in macOS-TCC-Berechtigungs-Pop-ups die angezeigte App von der App unterscheiden konnte, die tatsächlich die Berechtigung erhält
• Vor dem Patch war folgende Konstellation möglich
  • Application A fordert macOS auf, ein Pop-up zur Berechtigungszustimmung anzuzeigen
  • Das Pop-up sieht so aus, als käme es von Application B
  • Das Ergebnis der Nutzerzustimmung wird auf Application C angewendet
• Die drei Apps konnten voneinander verschieden sein; bei normaler Nutzung sind sie wahrscheinlich meist dieselbe App
• Das Kernproblem bestand darin, dass nicht ausreichend geprüft wurde, ob die im Pop-up angezeigte App und die App, die tatsächlich die Berechtigung erhält, übereinstimmen

Umfang des Patches und Korrekturen

• Anders als zunächst beschrieben wurde der Patch nur auf macOS Sequoia 15.5 angewendet
• macOS Ventura 13.7.6 und macOS Sonoma 14.7.6, die am selben Tag veröffentlicht wurden, wurden nicht gepatcht
• Beim Kompilieren und Ausführen des PoC in einer Sonoma-14.7.6-VM funktionierte die Schwachstelle weiterhin
• Apple Product Security änderte den Berichtsstatus auf „We’ve addressed the issue in all planned releases.“ und bestätigte später, dass für Ventura und Sonoma kein Patch für diese Schwachstelle geplant ist
• Damit bleiben Ventura und Sonoma letztlich für diese Schwachstelle anfällig

Wo TCC und Apple Events zusammentreffen

• TCC ist das zentrale Berechtigungssystem von Apples Betriebssystemen und arbeitet intern über den Daemon tccd sowie das private TCC-Framework
• Entwickler rufen die private API nicht direkt auf, aber öffentliche APIs rufen intern TCC-Funktionen auf, wenn sie benötigt werden
• tccd empfängt Nachrichten über Apples XPC API
• Vor dem Patch konnte eine App, die XPC-Nachrichten an tccd senden kann, eine manipulierte Nachricht schicken und so die App, die im Berechtigungs-Pop-up angezeigt wird, von der App trennen, die tatsächlich die Berechtigung erhält

Apple Events und das TCC-Datenmodell

• Apple Events sind ein Mechanismus für Interprozesskommunikation unter macOS und werden heute hauptsächlich für Automatisierung genutzt
• Apple-Events-Automatisierung lässt sich über Apples Open Scripting Architecture skripten
  • Die bekannteste Sprache ist AppleScript
  • Auch JavaScript kann verwendet werden
• Seit macOS Mojave 10.14 benötigen Apps für das Senden von Apple Events eine Nutzerzustimmung über TCC
• Das Ergebnis der TCC-Nutzerzustimmung wird in der SQLite-Datenbank Application Support/com.apple.TCC/TCC.db unterhalb des Home-Ordners des Nutzers gespeichert
• Eine typische TCC-Zeile enthält die anfragende App, den angefragten Dienst und das Ergebnis der Nutzerzustimmung
• Da Apple Events Berechtigungen pro empfangender App einschränken müssen, verwenden sie die Spalte indirect object
  • Diese Spalte enthält den Identifier der App, die Apple Events empfangen soll
  • Neben Apple Events verwendet auch der FileProviderDomain-Dienst diese Spalte

Struktur der verwundbaren XPC-Nachricht

• Das Problem lag in einem Logikfehler der Funktion TCCAccessRequestIndirect
• Diese Funktion verarbeitet Zugriffsanfragen, die die Spalte indirect object in TCC.db nutzen müssen
• Der Kern des PoC besteht darin, bei target_prompt gleich 2 zwei Felder getrennt zu befüllen
  • target_path: wird verwendet, um den im GUI-Berechtigungs-Pop-up angezeigten App-Namen zu ermitteln
  • target_identifier: wird tatsächlich in die Datenbank geschrieben und als Bundle-ID der App verwendet, die die Berechtigung erhält
• Obwohl TCCAccessRequestIndirect eine Funktion für indirect objects ist, ließ sie sich durch Einfügen eines leeren Strings als indirect object auch für mehrere TCC-Dienste verwenden, die diese Spalte nicht nutzen
• Dieser Fehler existierte in anderen Funktionen für Zugriffsanfragen nicht

Ausnutzungsbedingungen und Einschränkungen

• Die Ausnutzung der Schwachstelle gelingt nur, wenn der Nutzer im Berechtigungs-Pop-up auf Allow klickt
• Die nutzbaren TCC-Dienste waren begrenzt, umfassten aber wichtige Dienste wie Microphone und Camera
• Auch Berechtigungs-Pop-ups für den Zugriff auf bestimmte Verzeichnisse konnten gespooft werden, waren wegen zusätzlicher Sicherheitsschichten rund um Dateien aber weniger nützlich
• Es war auch möglich, eine bösartige App die Berechtigung nicht auf sich selbst, sondern auf eine andere App anwenden zu lassen
  • Das ist ein Pfad, der genutzt werden kann, wenn ein Angreifer eine andere App kontrollieren kann, diese App aber TCC-Berechtigungen benötigt

Täuschung über das Timing von Pop-ups

• Wenn ein Berechtigungs-Pop-up zufällig erscheint, könnten Nutzer misstrauisch werden und auf Don’t Allow klicken
• macOS-Apps können die Liste laufender Anwendungen und die aktuell vorderste App abfragen
  • Laufende Apps prüfen: NSWorkspace runningApplications
  • Vorderste App prüfen: NSWorkspace frontmostApplication
• Eine bösartige App kann warten, bis eine bestimmte App gestartet oder zur vordersten App wird, und dann ein auf deren Namen gespooftes Berechtigungs-Pop-up anzeigen
• Beispielsweise kann beim Start von FaceTime ein Camera-Berechtigungs-Pop-up und beim Start von Voice Memos ein Microphone-Berechtigungs-Pop-up gespooft werden
• Nutzer könnten ein Pop-up, das direkt nach dem Öffnen oder Wechseln zu einer App erscheint, irrtümlich für eine legitime Berechtigungsanfrage dieser App halten

Verbindung zu früheren TCC-Umgehungen

• Früher war eine TCC-Umgehung möglich, indem tccd den Home-Ordner des Nutzers über die Umgebungsvariable HOME bestimmte und dadurch ein gefälschter Home-Ordner samt gefälschter TCC.db platziert werden konnte
• Dieses Problem wurde mit einem Update Mitte Juli 2020 gepatcht; seitdem ermittelt tccd den Home-Ordner aus dem Benutzerinformationsverzeichnis des Betriebssystems
• Auch danach gab es Umgehungen, die Änderungen am Home-Ordner des Nutzers ausnutzten
  • Wojciech Reguła veröffentlichte CVE-2020-27937, das das Plug-in-System des GUI-Editors für Benutzerinformationen in macOS missbrauchte
  • Das Microsoft-Threat-Intelligence-Team veröffentlichte die powerdir-Umgehung über Import-/Export-Befehle
• Um den Home-Ordner eines Nutzers zu ändern, sind in der Regel zwei Dinge nötig
  • Root-Rechte
  • Nutzerzustimmung für einen bestimmten TCC-Dienst
• CVE-2025-31250 umgeht die Anforderung von Root-Rechten nicht, kann aber die notwendige TCC-Zustimmung über ein gespooftes Pop-up herbeiführen
• Wenn eine bösartige App den Nutzer zur Zustimmung verleitet und zusätzlich eine Root-Privilege-Eskalation erreicht, kann sie den Benutzerinformationspfad ändern und eine gefälschte TCC.db platzieren
• REG.db verfolgt gültige TCC.db-Dateien, aber TCC besitzt eine Funktion, mit der Apps Einträge zu REG.db hinzufügen können, sodass sich der Pfad zur platzierten TCC.db hinzufügen lässt

Grenzen der für Nutzer sichtbaren Berechtigungsverwaltung

• TCC ist ein System, das hinter dem Privacy & Security-Panel in System Settings arbeitet
• Zustimmungsergebnisse im Zusammenhang mit Apple Events werden im Bereich Automation angezeigt
• Im Privacy & Security-Panel können Nutzer erteilte Zustimmungen einsehen und in vielen Fällen einzelne Zustimmungen widerrufen
• Wenn ein Angreifer den Nutzer jedoch dazu brachte, Apple-Events-Berechtigungen zu erlauben, erschien dieses Zustimmungsergebnis nicht in System Settings
• Nutzer können Zustimmungen mit dem CLI-Tool tccutil widerrufen, doch dieses Tool ist nur begrenzt dokumentiert und den meisten Nutzern schwer bekannt
  • Als Apple-Dokumentation gibt es eine ältere Technical Q&A und eine IT training page

Endpoint Security und Erkennungsmöglichkeiten

• Apples Endpoint-Security-Framework unterstützt seit Kurzem die Überwachung von Änderungen an der TCC-Datenbank
• Ein Beitrag von Objective-See behandelt diese Änderung: Endpoint Security TCC database monitoring
• Wenn diese Funktion wie erwartet arbeitet, können Apps, die das Framework verwenden, Nutzer nachträglich darüber informieren, welcher App tatsächlich Berechtigungen erteilt wurden
• Diese Erkennungsmöglichkeit hatte allerdings nur in der kurzen Zeitspanne zwischen Apples Hinzufügen der Endpoint-Security-Events und dem Patch der Schwachstelle direkte Bedeutung

Apples Art der Behebung

• Eine Analyse des tccd-Binaries in macOS Sequoia 15.5 ergab, dass der finale Patch komplexer war als zunächst vermutet
• Nach dem Patch lassen sich TCC-Pop-ups auf dieselbe Weise nicht mehr spoofen
• Auch die Verwendung von TCCAccessRequestIndirect für andere TCC-Dienste durch Einfügen eines leeren Strings als indirect object scheint eingeschränkt worden zu sein
• Verwundbare Nachrichtenformen werden nun offenbar von tccd stillschweigend verworfen und lösen keine Aktion aus
• In einer einfachen Prüfung wirkte der Patch gut, für ein vollständiges Verständnis des Gesamtverhaltens ist jedoch weitere Analyse nötig

Verlauf von Meldung und Patch

• Diese Schwachstelle war der zweite an Apple gemeldete Bug und unter den von Apple gepatchten Meldungen der Fall, bei dem der Patch am längsten dauerte
• Der Meldeprozess umfasste die ursprüngliche Meldung, Nachfragen von Apple Product Security, die Weitergabe eines möglichen vollständigen TCC-Bypass-Pfads, Updates zu PoC-Tests, die Bestätigung des Reproduktionsstatus und mehrere Nachfragen zum Fortschritt
• Der vorgeschlagene einfache Patch bestand darin zu prüfen, ob die beiden Felder auf dieselbe App verweisen
• Apple antwortete mehrfach, dass die Untersuchung laufe, bat später um den Namen für die Credit-Nennung und veröffentlichte anschließend den Patch
• Die Schwachstelle erhielt den Namen „TCC, Who?“