- Das TCC-Berechtigungssystem von macOS konnte aufgrund einer Schwachstelle irreführende Berechtigungsanfrage-Pop-ups anzeigen
- Die Schwachstelle ist als CVE-2025-31250 registriert; dabei wird die Zustimmung des Nutzers auf eine andere App angewendet
- Es besteht die Möglichkeit eines Spoofing-Angriffs, bei dem eine bösartige App das Berechtigungsfenster im Namen einer vertrauenswürdigen App anzeigt, um die Zustimmung des Nutzers zu erschleichen
- Behoben wurde dies in Apple macOS Sequoia 15.5, andere Versionen sind jedoch weiterhin ungepatcht
- Hinzu kommen Schwierigkeiten bei der Prüfung und dem Widerruf des Berechtigungsverlaufs sowie die Möglichkeit, dass künftig ähnliche Schwachstellen auftreten
Wichtige Korrektur
- Diese Schwachstelle wurde zwar in macOS Sequoia 15.5 behoben, in macOS Ventura 13.7.6 und macOS Sonoma 14.7.6 ist sie jedoch noch nicht gepatcht
- Es wurde bestätigt, dass der Meldende in Apples Security Release Notes nicht erwähnt wurde
- In einer virtuellen Maschine wurde macOS Sonoma 14.7.6 direkt getestet und verifiziert, dass sich die Schwachstelle weiterhin ausnutzen lässt
- Es wird vermutet, dass Ventura 13.7.6 im selben Zustand ist
- Eine offizielle Antwort von Apple steht noch aus
Einführung
- Die Schwachstelle CVE-2025-31250 ermöglicht es Anwendungen, gefälschte Berechtigungsanfrage-Pop-ups unter macOS anzuzeigen
- Wenn „Application A“ ein Pop-up auslöst, wird darin „Application B“ angezeigt, während die Berechtigung des Nutzers letztlich auf „Application C“ angewendet wird
- Normalerweise sind diese drei Anwendungen identisch, durch diese Lücke konnten jedoch unterschiedliche Apps angegeben werden
- Dadurch entsteht ein gravierendes Problem für die Vertrauenswürdigkeit von Berechtigungsanfragefenstern
- Ähnliche „Spoofing“-Methoden wurden bereits zuvor etwa bei HackTricks vorgestellt, diese Schwachstelle ist jedoch deutlich einfacher auszunutzen
TCC
- TCC ist das zentrale integrierte Berechtigungsverwaltungssystem in Apple-Betriebssystemen
- Berechtigungen werden verwaltet, indem Nachrichten an den Daemon „tccd“ gesendet werden; die öffentliche API ruft dabei Funktionen des privaten TCC-Frameworks auf
- Der Daemon kommuniziert über Apples XPC-API
- Vor dem Patch dieser Schwachstelle war es möglich, mit beliebigen Nachrichten unterschiedliche Apps für die Anzeige des Berechtigungs-Pop-ups und für die tatsächliche Berechtigungsvergabe festzulegen
- Um zu verstehen, warum diese Lücke entstand, muss man Apple Events betrachten
Apple Events
Was sind Apple Events?
- Apple Events sind ein Mechanismus zur Interprozesskommunikation zwischen macOS-Apps
- Es handelt sich um ein Protokoll, das bis in die Zeit klassischer Bücher aus dem Jahr 1993 zurückreicht
- Auch nach der Einführung von macOS X wurde es an die neue Architektur angepasst und weiterverwendet
- Heute wird es vor allem für Automatisierung (Automation) eingesetzt, etwa über AppleScript und JavaScript
- Es ähnelt dem Script Host unter Windows und wurde auch schon als Vektor für Malware missbraucht
Apple Events und TCC
- Seit macOS Mojave 10.14 ist für das Senden von Apple Events die Zustimmung des Nutzers erforderlich
- In der Berechtigungsdatenbank von TCC (
TCC.db) werden die anfragende App, der Dienst und die Zustimmungsentscheidung gespeichert
- Da Apple Events Berechtigungen pro einzelner Ziel-App getrennt verwalten müssen, wird die Spalte indirect object in
TCC.db verwendet
- Die Funktion TCCAccessRequestIndirect des TCC-Daemons verarbeitet Nachrichten unter Verwendung dieser Spalte
- In dieser Funktion existierte ein Logikfehler, durch den sich die dem Nutzer angezeigte App von der App unterscheiden konnte, die die Berechtigung tatsächlich erhält
Proof of Concept (PoC)
- Das Swift-Codebeispiel manipuliert die Berechtigungsanfrage-Nachricht wie folgt
- Der Name der App im Pfad „spoofedBundle“ wird im Zustimmungs-Pop-up für den Nutzer angezeigt
- Die Bundle-ID von „actualBundle“ wird als tatsächliches Ziel der Berechtigungsvergabe gesetzt
- Das Ergebnis: Für den Nutzer sieht es so aus, als fordere eine vertrauenswürdige App die Berechtigung an, die Berechtigung geht jedoch tatsächlich an eine bösartige App
- Selbst wenn der Wert
indirect_object leer gelassen wurde, konnten mehrere TCC-Dienste angegriffen werden
- Dies führte zu einem Zusammenbruch der Vertrauenswürdigkeit der Nutzerzustimmung zu Berechtigungen
- Angreifer konnten Nutzer täuschen und beliebigen Apps den Erhalt von Berechtigungen ermöglichen
Ausnutzung der Schwachstelle
Einschränkungen und Besonderheiten
- Nur bestimmte TCC-Dienste sind anfällig, aber wichtige Dienste wie Microphone und Camera gehören dazu
- Bei Datei- und Ordnerberechtigungen ist die Wirkung wegen zusätzlicher Schutzmechanismen begrenzt
- Eine bösartige App kann dies zusammen mit Social Engineering nutzen, damit Nutzer stellvertretend für eine andere App zustimmen, die tatsächlich Berechtigungen benötigt
Die Bedeutung des Timings
- Der Zeitpunkt, zu dem das Pop-up erscheint, ist entscheidend
- Eine bösartige App kann laufende Apps und die aktuell im Vordergrund befindliche App erkennen und das Pop-up zum passenden Zeitpunkt anzeigen, um den Nutzer zu verwirren
- Wenn beispielsweise FaceTime gestartet wird und ein Pop-up für die Camera-Berechtigung erscheint, kann der Nutzer dies für eine legitime Anfrage halten
- Ebenso ist ein Szenario denkbar, in dem beim Starten von Voice Memos eine Microphone-Berechtigungsanfrage gespooft wird
- Wird die Schwachstelle im passenden Kontext und zum richtigen Zeitpunkt ausgenutzt, steigen die Erfolgschancen erheblich
Frühere Schwachstellen erneut betrachtet
- Es gab Schwachstellen, die ausnutzten, dass der Pfad von
TCC.db abhängig vom Home-Verzeichnis des Nutzers bestimmt wird
- Bis 2020 konnte allein durch das Ändern der Umgebungsvariable
HOME eine gefälschte TCC.db verwendet werden ($HOMERun)
- Auch nach dem Patch sind zwar Root-Rechte und die Zustimmung des Nutzers erforderlich, in Kombination mit Social-Engineering-Spoofing bleibt jedoch eine Umgehung von Berechtigungen möglich
- Eine bösartige App kann nach erschlichener Zustimmung durch Ändern des Home-Verzeichnisses und Hinzufügen einer registrierten Datenbank auf eine gefälschte
TCC.db ausweichen
- In Tests wurde bestätigt, dass sich TCC auf diese Weise tatsächlich beeinflussen lässt
Zeitleiste
1.
- 2024-05-02: Erste Meldung an Apple Product Security sowie Übermittlung zusätzlicher Nachrichten
2.
- 2024-05-03: Apple Product Security bat um weitere Erläuterungen und erhielt eine Antwort
- Am selben Tag wurde die Möglichkeit einer vollständigen TCC-Umgehung entdeckt und erneut an Apple gemeldet
3.
- 2024-05-04: Fortgesetzte PoC-Tests und weitere Status-Updates
4.
- 2024-05-06: Apple Product Security bedankte sich für die bereitgestellten Informationen
5.
- Danach wurde weiterhin regelmäßig nach dem Patch-Status gefragt und der Zustand überprüft; von 2024-06 bis 2025-02 bestand fortlaufender Kontakt mit Apple, die Schwachstelle blieb jedoch lange ungefixt
6.
- 2025-05-12: Veröffentlichung des Patches für den betreffenden Bug
Fazit
Sonstiges
- TCC wird in der App System Settings im Bereich Privacy & Security (früher Security & Privacy) sowie im entsprechenden Automation-Abschnitt angezeigt
- Zustimmungen im Zusammenhang mit Apple Events sind in der GUI jedoch nicht sichtbar, wodurch ein direkter Widerruf für Nutzer schwierig ist
- Über das CLI-Tool
tccutil ist ein Widerruf möglich, dies ist aber kaum bekannt
- Kürzlich wurde im Apple Endpoint Security Framework eine Funktion zur Überwachung von Änderungen an der TCC-Datenbank hinzugefügt
- Falls diese ordnungsgemäß funktioniert, könnte sie Nutzer darüber informieren, welche App die Berechtigung tatsächlich erhalten hat, und so Missbrauch erschweren
Apples Patch
- Der eigentliche Patch ist komplex; von außen beliebig erzeugte Nachrichten mit gesetztem indirect object werden nun von
tccd stillschweigend ignoriert
- Tests des Verhaltens bestätigten, dass Spoofing damit nicht mehr möglich ist
- Sollte der Patch unvollständig sein, könnten in künftigen Updates zusätzliche Maßnahmen nötig werden
Abschließende Gedanken
- Dieser Schwachstelle wurde der Name „TCC, Who?“ gegeben
- Aus Sicht eines Sicherheitsforschers wird die Bedeutung der Vertrauenswürdigkeit von Berechtigungssystemen erneut unterstrichen
- Es wird angedeutet, dass auch künftig ähnliche Lücken entdeckt werden könnten
- Nutzer sollten Berechtigungs-Pop-ups von macOS nicht blind vertrauen
1 Kommentare
Hacker-News-Kommentare
In der winzigen Hoffnung, dass das jemand bei Apple liest, wiederhole ich etwas, worum ich schon lange bitte: Apple soll bitte damit aufhören, jederzeit zufällig Dialoge einzublenden, die sagen, man solle „jetzt das Passwort des lokalen Administrators eingeben“, nur weil der Computer gerade Lust hat, ein Update oder irgendetwas anderes zu installieren. Mit nur grundlegenden Kenntnissen kann man im Web problemlos ein täuschend ähnliches Fake-Popup bauen, und die meisten Nutzer außerhalb vielleicht der technisch versiertesten 20 % kommen gar nicht auf die Idee zu prüfen, ob das echt ist oder nur eine Fälschung im Browser. Um solche Probleme grundsätzlich zu verhindern, müsste man den Nutzern angewöhnen, dass legitime Software nicht plötzlich mitten in der Arbeit ohne Vorwarnung einen Passwortdialog zeigt — aber die aktuelle Sicherheits-UI von macOS tut genau das Gegenteil. Man sollte das etwa über ein buntes, auffälliges Symbol in der Menüleiste oder wie bei Windows mit einem kurz eingeblendeten Sicherheitsbildschirm lösen. Das aktuelle UI-Design ist wirklich problematisch
Was ich an solchen Popups am meisten hasse: Ich weiß nie, warum das verlangt wird, was passiert, wenn ich ablehne, oder was ich tun muss, wenn ich diese Einstellung später ändern will. Wenn eine App stattdessen sagt „Öffnen Sie die Einstellungen und geben Sie Berechtigung XXX“, dann sehe ich klar, welche App, welche Berechtigung und welcher Schalter gemeint ist. Passwort-Popups bieten diese UX nicht. Deshalb mag ich das Konzept von „Capabilities“ immer weniger — die UX ist einfach furchtbar, und das scheint fast unvermeidlich zu sein. Es würde am Ende nur auf etwas hinauslaufen wie „Um die App vollständig zu nutzen, erlauben Sie bitte <root my computer>“, weil Anbieter ihre Meldungen immer so formulieren würden. Eine völlig nutzlose UX
Wenn macOS modale Fenster weiterhin an das jeweilige Fenster angeheftet darstellen würde, wäre das vielleicht etwas weniger schlimm. Es würde das Problem nicht vollständig lösen, aber immerhin abmildern. Wenn das Modal wie heute einfach über der Toolbar schwebt, wirkt es auf den ersten Blick wie etwas, das „zur App selbst gehört“. Schon bei Steve Jobs’ Aqua-Demos wurde betont, dass solche frei schwebenden Modals die Benutzbarkeit verschlechtern. Ich denke, das ist heute so, weil Apple einen seltsamen Drang hat, auf allen Bildschirmen mobile UI zu verwenden
Meine technisch wenig versierte Familie versteht nicht einmal den Unterschied zwischen dem lokalen Gerätepasswort und dem iCloud-/Apple-ID-Passwort und tippt am Ende einfach alles Mögliche ein, bis etwas funktioniert (was an einer unklaren und inkonsistenten UI liegt). Früher hat sich Apple über Vistas UAC lustig gemacht, aber inzwischen bauen sie selbst jede Menge plötzliche Hinweise und schlampige UI
Ich bin vor Kurzem von Linux auf den Mac gewechselt, und diese zufällig auftauchenden Root-Passwort-Popups haben mich wirklich verwirrt. Es wurde nie erklärt, welche App oder welcher Befehl Root-Rechte anfordert oder warum. Nach ein paar Zustimmungen habe ich dann einfach angefangen, alles abzulehnen. Seitdem tauchen keine Popups mehr auf. Aber ich habe immer noch keine Ahnung, wofür sie überhaupt erschienen sind oder warum sie jetzt weg sind
Ich möchte diesen klassischen Artikel noch einmal empfehlen: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/
Passkey-Popups sind sicherheitstechnisch ein besonders schwerer Fehler, weil sie sich überhaupt nicht von JavaScript-Popups unterscheiden
In solchen Situationen bin ich dem eingebauten Fingerabdrucksensor wirklich dankbar. Normalerweise nutze ich den Laptop nur mit geschlossenem Deckel an einem externen Monitor, aber wenn eine Systemauthentifizierung nötig ist, klappe ich ihn extra auf und authentifiziere mich per Fingerabdruck
Die Wendung: In Wirklichkeit gab es so einen Dialog gar nicht! Du bist bereits darauf hereingefallen
Ich möchte noch auf eine wichtige Information hinweisen, indem ich mich an den aktuell beliebtesten Kommentar anhänge — zu diesem Artikel gibt es ein wichtiges Update: https://news.ycombinator.com/item?id=43969087
Mich würde interessieren, welches Bedrohungsmodell beim Anklicken eines Fake-Popups angenommen wird. Wenn es nicht wirklich das System ist, ist das dann nicht letztlich eine bedeutungslose Interaktion?
Beim Einloggen in iCloud erscheint ein Popup, das das lokale Passwort des Computers verlangt, und wenn man es eingibt, wird dieses Passwort zu den iCloud-Servern hochgeladen
Ich habe kürzlich erfahren, dass man Mac-Apps nicht in die systemweite Applications, sondern in die Applications im Home-Verzeichnis (~/Applications) installieren sollte — sinnvoll natürlich nur auf einem Computer, den nur eine Person benutzt. Wenn man sich selbst zu einem Nicht-Admin-Benutzer macht und Apps in ~/Applications installiert, verschwinden die lästigen Update-Berechtigungsanfragen. Die meisten Apps aktualisieren sich dann auch ohne Administratorrechte. Nur Ausnahmen wie Tailscale, die OS-Integration brauchen, benötigen noch zusätzliche Rechte. Empfohlen wurde das übrigens von der App Pareto Security
Leider kennen fast alle App-Entwickler diesen Ansatz ebenfalls nicht, und viele Apps bestehen sogar darauf, nur unter /Applications installiert zu werden, sodass sie anderswo gar nicht funktionieren
Wenn Apps in ~/Applications installiert sind, können sie sich zwar ohne Root automatisch aktualisieren, aber damit kann auch verdächtiger Code sie leichter ohne Root-Rechte überschreiben
Ich nutze macOS 15.4.1, und bei mir gibt es den Ordner ~/Applications selbst gar nicht
Klingt interessant! Für mich ist das schwierig, weil ich im Alltag unbedingt ein Admin-Konto brauche, aber für Leute, auf die das passt, ist das wirklich ein nützlicher Ansatz
Der Inhalt dieses Artikels braucht eine wichtige Korrektur. Zuvor hieß es, die CVE sei in macOS Sequoia 15.5 behoben worden, tatsächlich wurde der Patch aber nicht in macOS Ventura 13.7.6 und macOS Sonoma 14.7.6 aufgenommen, die am selben Tag veröffentlicht wurden. Ich hatte angenommen, Apple würde den Patch selbstverständlich in alle Versionen einpflegen, und es deshalb so geschrieben. Dann habe ich in den Security-Release-Notes nachgesehen und festgestellt, dass mein Name in den beiden anderen Versionen nicht auftaucht, also habe ich Apple direkt kontaktiert. Eine Antwort habe ich noch nicht bekommen. Für einen direkten Test habe ich eine VM gestartet, macOS Sonoma 14.7.6 gepatcht und meinen PoC ausgeführt — die Schwachstelle funktioniert weiterhin. Ich vermute, dasselbe gilt für Ventura 13.7.6. Ich verstehe nicht, warum Apple den Patch nicht eingebaut hat. Wenn es neue Informationen gibt, werde ich den Artikel erneut aktualisieren
Das TCC-System von macOS gilt als robuste Datenschutzmaßnahme, aber wenn man bedenkt, wie leicht es sich mit einem einzigen Datenbankeintrag umgehen lässt, hinterlässt das einen bitteren Beigeschmack. Das Zustimmungs-Popup des Nutzers hat gegenüber tatsächlichen Datenbankmanipulationen wenig Bedeutung, besonders in Entwicklungsumgebungen mit deaktiviertem SIP. Letztlich ist das eine Vertrauensfrage. Es ist fraglich, ob Zustimmung auf UX-Ebene überhaupt noch eine echte Sicherheitsgrenze darstellt. Wir verlassen uns zunehmend auf Berechtigungs-Popups auf OS-Ebene, aber wenn diese Grenze in Wirklichkeit nur eine Illusion ist — oder bloße Inszenierung —, dann sollten wir neu darüber nachdenken, wie Berechtigungsvertrauen nicht nur „angezeigt“, sondern tatsächlich aufrechterhalten wird
Ich erinnere mich daran, wie in den „I’m a Mac and I’m a PC“-Werbungen solche Dinge bei Vista verspottet wurden. Und jetzt ist mein Mac sogar noch schlimmer als Vista. Wirklich frustrierend
Der Kompromiss zwischen Sicherheit und Erweiterbarkeit scheint unvermeidlich zu sein. Andererseits hat sich die Grundlinie im Vergleich zu früher auch verschoben. Wenigstens ist macOS nicht so von bösartigen Prozessen überlaufen wie Windows damals. Oder vielleicht habe ich einfach nur Glück und bin vorsichtig
Nur aus Neugier: Was genau hat dich daran besonders genervt?
Das TCC-System war von Anfang an ein lückenhaftes Konstrukt. Es schikaniert nur legitime Entwickler und bombardiert Nutzer mit Berechtigungs-Popups, während bösartige Apps diese „Sicherheitsshow“ auf vielfältige Weise umgehen, wie Forscher immer wieder zeigen. Ich bin kein Sicherheitsforscher, aber als Mac-Entwickler habe ich selbst mehrere Umgehungsmöglichkeiten gefunden. Ich frage mich ernsthaft, ob Apple-Ingenieure die Technik, die sie einsetzen, überhaupt verstehen. Ich frage mich auch, wie viele traditionelle Mac-Entwickler überhaupt noch übrig sind
Ich nutze einen Firmen-Mac und bekomme regelmäßig die Meldung „Slack versucht, ein neues Helper Tool zu installieren“. Ich habe keine Ahnung, was das ist oder warum das passiert. Ich habe das IT-Team gefragt, aber die wussten auch nicht, wie man das prüft. Ich denke oft, dass sich das missbrauchen ließe, weil ständig nach dem Passwort gefragt wird, und selbst wenn ich jedes Mal auf Abbrechen klicke, kommt es immer wieder
Dieser Dialog kommt vom System-Management-Framework. Dabei versucht Slack, ein privilegiertes Helper Tool zu installieren, damit es sich selbst aktualisieren kann, egal wo es installiert wurde und unabhängig davon, welcher Benutzer es installiert hat
Immer wenn so ein Popup erscheint, habe ich keinerlei Möglichkeit zu wissen, anhand welcher Information ich über Zulassen oder Ablehnen entscheiden sollte, also klicke ich immer nur auf Abbrechen
Ich nutze Slack als Web-App (aber nicht im Browser, sondern in einem separaten Fenster) https://support.apple.com/en-us/104996 Discord kann man genauso verwenden. Für mich fühlt sich das deutlich angenehmer an als Electron-Apps. Bei den meisten Electron-Apps ist dieser Ansatz besser
Ich habe das „Helper-Tool“-Popup selbst noch nie gesehen, aber ich verstehe nicht, warum eine simple Messaging-App wie Slack solche Rechte brauchen sollte. Es wäre wohl gut, den Slack-Support zu fragen (und zu hoffen, dass man tatsächlich eine ordentliche Antwort bekommt)
Wie bei Apps, die ein Passwort brauchen (zum Beispiel Binärdateien, die unter Linux nur als Root laufen), besteht ganz klar Missbrauchspotenzial. Am Ende ist es eine Frage des Vertrauens darin, ob der Entwickler und die App echt sind. An dem Tag, an dem Apple Drittanbieter-Apps grundsätzlich keine Root-Rechte mehr geben kann, wäre der Mac komplett zu einem walled garden geworden und hier auf HN gäbe es massenhaft empörte Kommentare. Deshalb ist es wichtig, ein gesundes Misstrauen zu haben und Apps wie Slack, bei denen der Bedarf nicht klar erkennbar ist, keine Root-Rechte zu geben
Der Eingabefokus wird gewaltsam weggenommen, sodass Text, den man gerade in eine Nachricht tippte, plötzlich in das Passwortfeld eingegeben wird. Eine extrem nervige Erfahrung
Die Popups stauen sich zeitversetzt an. Wenn ich nach dem Wochenende den Computer einschalte, erscheinen sie immer wieder hintereinander, bis ich Slack einfach beende. Das geht seit einem Jahr so. Ich weiß nicht, wie man Slack diese Berechtigung wieder entzieht, und das wirkt etwas bösartig
Solche „Sicherheits“-Blocker sind wirklich dumm. Sie trainieren Menschen eher dazu, dümmer zu werden. Heute ist etwas vielleicht echt, morgen vielleicht nicht mehr. Ich bekomme ständig Anrufe von Banken, die unter dem Vorwand des „Identitätsschutzes“ meine persönlichen Daten abfragen, und solche Mechanismen trainieren Menschen letztlich dazu, Fremden persönliche Informationen zu geben
Ich bin kein macOS-Entwickler, aber ich habe mich gefragt, ob nicht jede beliebige (bösartige) App einfach den Stil der System-Popup-Fenster nachahmen und so das Benutzerpasswort stehlen kann
VSCode zeigt auf meinem von der Firma bereitgestellten Mac dasselbe Popup. Ich ignoriere es seit Jahren einfach
Bei allen Electron-basierten Apps erscheint dieses Popup, wenn man mehrere OS-Benutzerkonten verwendet
nordVPN zeigt dasselbe Verhalten
Apple hat volle 12 Monate gebraucht, um einen Patch bereitzustellen. Das kommt mir ziemlich lang vor. <i>2024-05-04 mehrere Update-Meldungen hinterlassen, PoC wird weiter getestet</i> <i>2025-05-12 Patch wurde veröffentlicht</i>
Adobe Creative Cloud lässt weiterhin mehrere Prozesse im Hintergrund laufen, selbst wenn man die Hintergrundausführung in den Betriebssystemeinstellungen ausdrücklich deaktiviert
Ich mag die Forschung dieser Person wirklich sehr, und sie scheint auch ausgesprochen gut zu präsentieren