Rootpipe: Security Bug im XPC Service writeconfig gefixt
Writeconfig, ein spezielles Hilfsprogramm für die Systemeinstellungen und das Command-Line-Tool systemsetup, prüfte vor OS X 10.10.3 nicht korrekt, ob es von den Systemeinstellungen selbst aufgerufen wurde oder aber von irgendeinem anderen nicht autorisiertem Programm.
Der XPC-Service writeconfig
Writeconfig ist dieses Programm: -rwxr-xr-x 1 root wheel 155200 Mar 6 15:46 /System/Library/PrivateFrameworks/SystemAdministration.framework/XPCServices/writeconfig.xpc/Contents/MacOS/writeconfig
Apple teilt, wie hier beschrieben, sicherheitskritische Programme in einzelne XPC-Dienste auf. Damit kann zusätzlich zu einer App-Sandbox noch mehr Sicherheit erreicht werden, indem potentiell gefährliche Tätigkeiten einer App in einen eigenen Adreßraum ausgelagert werden. Typischerweise zerteilt man eine App so in XPC-Services, daß jeder XPC-Service auf eine andere System-Ressource zugreift.
Diese Trennung erhöht die Sicherheit, weil damit die unterschiedlichen benötigen Privilegien voneinander getrennt werden. Wird ein Teil kompromittiert, sind die anderen Teile davon unberührt. Der Angreifer muß alle Einzelteile übernehmen, wenn er alle Rechte der App übernehmen will, und es ist nicht damit getan, in ein einziges monolithisches Binary einzubrechen, denn das gibt es aufgrund der Zerlegung ja nicht. Es ist so als ob man nicht einen Werkzeugkasten (monolithische App) hat, der Messer und Säge enthält, sondern Messer und Säge in getrennten Kästen wegschließt. Erbeutet der Angreifer eine Kasten (XPC-Service), dann kann er nur sägen oder schneiden, aber nicht beides. Der mögliche Schaden wird also durch die Aufteilung der gefährlichen Werkzeuge (Programm-Teile) auf verschiedene Kästen (XPC-Dienste) begrenzt.
Typischerweise ist ein XPC-Service nur aufrufbar von der App, zu der er gehört. Mit Hilfe von sogenannten Entitlements wird festgelegt, wer unter welchen Bedingungen den XPC-Service benutzen darf. Writeconfig sollte nur von den Systemeinstellungen und systemsetup verwendet werden dürfen.
Writeconfig ist ein XPC-Service, der offenbar Konfigurationsdateien auf der Platte verändern kann und das erfordert in manchen Fällen Root-Rechte, zum Beispiel in /etc/apache2/users/. Dieses Privileg, mit Systemrechten beliebige Konfigurationsdateien verändern zu können, wird in dem Dienst gekapselt, damit nicht jeder Angriff auf andere Teile der Systemeinstellungen oder systemsetup diese Rechte an den Angreifer liefert.
Der Rootpipe Bug
Die Entitlements, die einen Zugriff auf diesen Service nur den System Settings erlauben sollen, wurden nicht korrekt überprüft. Apple hat das mit 10.10.3 behoben, nachdem Emil Kvarnhammar den Fehler gefunden und Rootpipe getauft und an Apple gemeldet hatte. Man erlaubte sozusagen jedem Angreifer, den Kasten mit dem Messer darin zu benutzen, obwohl nur der Küchenchef dieses zum Kartoffelschneiden nutzen sollte by design.
Writeconfig hat eine Methode, um eine Datei mit gegebenen Daten an einem bestimmten Pfad mit gewünschten Posix-Rechten anzulegen. Emil hat damit eine Datei mit den Posix-Rechten 04777 angelegt, was -rwsrwxrwx 1 root wheel entspricht. Diese ausführbare Datei läuft aufgrund des Set-User-Id-Bits und Owner Root unter Root, egal wer sie startet. Somit konnte sich jeder Root-Rechte besorgen.
Der Fehler liegt in der Validierung des Zugriffs auf einen XPC-Service. XPC-Services wurden 2011 mit 10.7 eingeführt. Der Bug kann also schon sein 2011 enthalten gewesen sein im schlimmsten Fall.
Bewertung
Emil nennt diesen Bug, der einem lokalen User Root-Rechte verschaffen kann, eine versteckte Hintertür in OS X. Ich halte das für übertrieben, weil man eine Hintertür besser verstecken könnte, wenn man Hersteller des Betriebssystems ist. Für mich sieht es nach einem Fehler durch Übersehen aus. "Hintertür" bringt aber bessere Schlagzeilen. Und einen Rüffel von mir.
Emil schreibt selbst, daß anscheinend die Zugriffsüberprüfung durch das von seinem Exploit nicht übergebene Autorisierungs-Objekt schlicht ausfällt, weil Aufrufe an nil ignoriert werden. Der Fix besteht dann darin, bei nicht vorhandenem Autorisierungs-Objekt auch keinen Zugriff zu gewähren. Ein schlampiger Fehler, aber keine Hintertür.
In 2007 hatte Apple schon einmal ein Problem mit Writeconfig. Damals war es jedoch selbst ein Setuid-Binary. Heute ist das nicht mehr der Fall. Damals wurde der andere Fehler auch aufgebauscht.
Der Bug ist nun zwar behoben, aber ich hoffe, Apple nimmt das zum Anlaß, ähnliche Code-Stellen nochmal durchzusehen, um vergleichbare Probleme zu beheben, bevor die falschen Leute sie entdecken.