Lücke in macOS: Code von vertrauten Apps lässt sich unbemerkt austauschen

Inhaltsverzeichnis Weiterlesen nach der Anzeige Zwei Sicherheitsforscher demonstrieren, wie Angreifer unter bestimmten Umständen den ausführbaren Code installierter macOS-Apps austauschen können, ohne dass macOS die manipulierte App blockiert oder eine Warnung ausgibt. Talal Haj Bakry und Tommy Mysk, die den datenschutzorientierten iOS-Browser Psylo entwickeln, dokumentieren den Bug in einem am 23. Juli veröffentlichten Blogbeitrag. Darin zeigen sie am Beispiel des Messengers Signal, wie sich die ausführbare Programmdatei im App-Bundle austauschen lässt, ohne dass das Sicherheitssystem Gatekeeper eine erneute Prüfung auslöst. Betroffen sind mindestens macOS 26 Tahoe und die Beta-Versionen von macOS 27 Golden Gate; die Forscher gehen davon aus, dass sich ältere Versionen ähnlich verhalten. Nur bestimmte Apps anfällig Betroffen sind ausschließlich Apps, die Nutzer außerhalb des Mac App Store installiert und bereits mindestens einmal gestartet haben. In diesem Fall hat Gatekeeper die Signatur und Notarisierung bereits geprüft. Programme aus dem App Store gehören dem Benutzer „root“ und lassen sich ohne höhere Rechte nicht manipulieren. Bei manuell installierten Apps ist dagegen der aktuelle Benutzer Eigentümer. Doch selbst der Eigentümer der App kann die Binärdatei im Bundle (unter „Contents/MacOS“) zunächst nicht einfach austauschen, auch nicht mit sudo im Terminal. Ohne die zusätzliche Berechtigung zur „App-Verwaltung“ verhindert macOS die Manipulation. Anders sieht es aus, wenn die App zuvor als Zip- oder Tar-Archiv gesichert, aus dem Programmeordner gelöscht und anschließend wiederhergestellt wird. Dies kann ein Benutzer ohne weitere Authentifizierung durchführen – und ebenso Schadsoftware, die mit Benutzerrechten ausgeführt wird. Erst danach sorgt offenbar ein Bug in macOS dafür, dass sich die Binärdatei der App unbehelligt durch beliebigen Code oder ein Skript ersetzen lässt. Bakry und Mysk führen das Verhalten darauf zurück, dass macOS die ausführbare Binärdatei und die übrigen Inhalte des App-Bundles getrennt prüft. Im Proof-of-Concept bleibt der Rest des Bundles unverändert und damit behält das Siegel für die Ressourcen seine Gültigkeit. Die veränderte Binärdatei ist hingegen ad-hoc-signiert, weshalb macOS diese auf demselben System ohne Weiteres ausführt. Da sie im Bundle von Signal liegt, erbt sie dessen Identität. Ursprüngliche Entitlements und erteilte TCC-Rechte erbt der neue Code jedoch nicht, weshalb Nutzer etwa Zugriffe auf den Schlüsselbund oder geschützte Systemressourcen wie Kamera und Ordner erneut bestätigen müssen. Die Systemdialoge zeigen dabei jedoch das App-Icon und den Namen der Signal-App. Mac & i kann das Verhalten nachstellen Weiterlesen nach der Anzeige Die Entdecker der Lücke betonen, dass das Problem nicht an der als Beispiel gewählten App Signal liegt. Auch Programme wie Brave Browser, Cursor, Mullvad Browser, Proton Mail, Slack, Visual Studio Code und Xcode ließen sich auf diese Weise manipulieren. Wir haben das Signal-Beispiel mit macOS 26.6 Tahoe (Release Candidate) und macOS 27 Golden Gate Beta 4 „erfolgreich“ nachstellen können. Zudem haben wir es exemplarisch mit dem Browser Brave und dem Texteditor BBEdit in der Download-Version verifiziert. Das klappte sowohl mit einer ad-hoc-signierten Binärdatei als auch bei einer Codesignierung mit Entwicklerzertifikat. Wir können zudem bestätigen, dass macOS bei bislang nicht gestarteten Apps die Manipulation erkennt und den Start verweigert. Apples Reaktion Bakry und Mysk geben an, dass sie vor der Veröffentlichung des Artikels Apple erstmals am 4. Juni 2026 kontaktiert haben. Ihren Angaben zufolge stuft der Konzern das berichtete Verhalten von macOS nicht als Sicherheitslücke ein und schloss den Fall am 14. Juli. Als Begründungen werden unter anderem genannt, dass hier keine Sicherheitsmechanismen umgangen wurden und Gatekeeper dafür gedacht sei, Programme direkt nach dem Download zu prüfen und nicht Dateien und Programme im Besitz des Benutzers, die er selbst manipuliert hat. Tatsächliche Risiken Die Forscher sehen das differenzierter: Zwar betonen auch sie, dass sie weder das TCC-System von macOS, Gatekeeper noch die Codesignierung umgangen haben. Dennoch ermögliche es der Bug Angreifern, das Vertrauen der Nutzer in installierte Apps auszunutzen. Wenn der manipulierte Signal-Messenger beispielsweise auf den Desktop zugreifen will, erscheint die Systemaufforderung von macOS erneut, die sich optisch nicht von der echten App unterscheidet. In der Regel dürften Anwender diesen Anfragen eher unkritisch gegenüberstehen und sie nochmals bestätigen. Bakry und Mysk schlagen vor, dass macOS App-Bundles nach jeder Änderung erneut validiert. Außerdem sollten Berechtigungsdialoge neben Name und Symbol der App auch die tatsächliche Entwickleridentität (Team-ID) des anfragenden Prozesses anzeigen. Für die meisten Nutzer schätzen wir das unmittelbare Risiko als gering ein: Das setzt voraus, dass auf dem Mac bereits Schadcode mit den Rechten des angemeldeten Benutzers läuft – etwa durch eine bösartige oder kompromittierte App. Denn nur diese wäre in der Lage, andere Programme derart zu manipulieren. Auch dürfte der Aufwand recht groß sein, eine veränderte Version einer App zu erstellen, die dem Original so ähnlich sieht, dass Anwender keinen Verdacht schöpfen. Was können Anwender tun? Für Mac-Nutzer bleibt der altbewährte Rat, keine Software von unbekannten Download-Seiten zu laden oder gar geknackte Programme zu verwenden. Fügen Sie keine Shell-Befehle von unbekannten Quellen ungeprüft ins Terminal ein. Wenn Software Sie dazu auffordert, sollten Sie hellhörig werden. Zudem empfiehlt es sich, besonders achtsam zu sein, sobald eine App bereits gewährte oder unpassende Berechtigungen anfragt. In dem Fall können Sie das kostenlose Tool Apparency nutzen. Es zeigt die Signatur- und Notarisierungsinformationen einer App an. Es erkennt, wenn die Entwickleridentität oder die Team-ID der Binärdatei vom erwarteten Anbieter abweichen oder eine verifizierbare Signatur fehlt.