sideeffect42/rootpipetesterRootPipe (CVE-2015-1130) und Phoenix (CVE-2015-3673) Schwachstellen-Testprogramm für Mac OS X 10.2.8 und neuer
RootPipe Tester ist eine kleine Anwendung, die auf deinem Mac läuft (Mac OS X 10.2.8 oder höher, sowohl PowerPC als auch Intel) und versucht, sowohl den RootPipe-Exploit (CVE-2015-1130) als auch den Phoenix-Exploit (CVE-2015-3673) zu verwenden, um eine Privilegienerweiterung zu erreichen.
Ob dein Mac verwundbar ist, hängt von der Version von Mac OS X ab, die du verwendest, aber der Erfolg hängt auch von den Einstellungen ab, die du gesetzt hast.
Mit RootPipe Tester habe ich eine Ein-Klick-Lösung für dich erstellt, mit der du überprüfen kannst, ob du verwundbar bist, ohne umfangreiche Tests und Versuche durchführen zu müssen.
Lade das Disk-Image von der Release-Seite dieses Repositorys herunter oder kompiliere es selbst, wenn du es bevorzugst.
Mounte das Disk-Image und führe die darin enthaltene Anwendung aus (es ist sicher, RootPipe Tester direkt vom Disk-Image auszuführen).
Klicke auf „Start Test“ und lass den Test durchlaufen (du erkennst, dass er fertig ist, an „Running…“ im Fenstertitel).
Um genaue Ergebnisse zu erhalten, empfehle ich, deinen Mac neu zu starten und den Test bei einem „frischen Login“ erneut auszuführen.
Wenn mindestens einer der Testläufe ein verwundbares System erkannt hat, solltest du dir den PANIK-Abschnitt ansehen.
Nein! Bleib ruhig und lies die Anleitung, die zu deiner Systemversion passt.
Hinweis: „Nicht verwundbar“ bei der Benutzerautorisierung bedeutet, dass das System entweder keinen Zugriff gewährt oder einen Autorisierungsdialog einblendet, der dich auffordert, dich als Administrator-Benutzer zu authentifizieren.
In gewissem Maße ist auch dies eine Privilegienerweiterung, denn die Admin-Gruppe hat nicht so viele Rechte wie root, aber in der Standardkonfiguration von sudo kann jeder Benutzer in der Gruppe „admin“ durch die Eingabe seines Passworts root erhalten, sodass derselbe Effekt auch einfach durch die Ausführung von sudo erzielt werden kann.
Aktualisiere so bald wie möglich auf 10.10.3, um sicherzustellen, dass das System die Entitlements für das writeconfig-Binary korrekt durchsetzt. (Zumindest behauptet Apple das.)
Falls du aus irgendeinem Grund nicht auf 10.10.3 aktualisieren kannst, wirf einen Blick in den Abschnitt für OS X 10.9 Mavericks.
Mavericks lässt einen Angreifer mit nil-Autorisierung durchkommen, du befindest dich also in einer viel schwierigeren Lage als bei älteren Versionen von Mac OS X.
Vielleicht möchtest du dir can_I_suid ansehen.
Testergebnisse:
Verwundbar
Du solltest „Passwort zum Entsperren jedes Systemeinstellungs-Bereichs verlangen“ im Sicherheitsbereich der Systemeinstellungen aktivieren.
Testergebnisse:
Nicht verwundbar
Glückwunsch! Du hast eine der sichersten Versionen von Mac OS X (zumindest was RootPipe betrifft).
Auf diesen Systemen funktioniert „Passwort zum Entsperren jedes Systemeinstellungs-Bereichs verlangen“ (in Tiger „Passwort zum Entsperren jeder sicheren Systemeinstellung verlangen“) im Sicherheitsbereich der Systemeinstellungen ordnungsgemäß und sollte wirklich aktiviert sein!
Hinweis: Wenn das Kontrollkästchen „Passwort verlangen“ nicht aktiviert ist, entsperrt das System sichere Systemeinstellungs-Bereiche bei jedem Login. Wenn du ein Administrator-Konto verwendest, macht das dein System verwundbar, bis du das Schloss in den Systemeinstellungen nach jedem Login manuell geschlossen hast.
Testergebnisse:
Nicht verwundbar
Anders als bei späteren Systemen hat das Kontrollkästchen „Passwort zum Entsperren jeder sicheren Systemeinstellung verlangen“ im Sicherheitsbereich der Systemeinstellungen in Panther nicht die Wirkung, diesen Exploit vollständig zu verhindern. Ich empfehle trotzdem, es zu aktivieren.
Um dein System zu sichern, empfehle ich dringend, ausschließlich ein Standard-Benutzerkonto zu verwenden und nach Änderungen an den Einstellungen in den Systemeinstellungen das Schloss immer manuell zu „schließen“.
Allein das Schließen der Systemeinstellungen macht die Autorisierung nicht ordnungsgemäß ungültig, und dieser Exploit funktioniert, bis du dich abmeldest, obwohl die Systemeinstellungen-GUI einem Standard-Benutzer ein geschlossenes Schloss anzeigt.
Testergebnisse:
Nicht verwundbar
Anders als spätere Systeme bietet Jaguar kein Kontrollkästchen „Passwort zum Entsperren jeder sicheren Systemeinstellung verlangen“, entsperrt aber bei der Anmeldung für alle Administrator-Benutzer dennoch sichere Systemeinstellungs-Bereiche.
Um dein System zu sichern, empfehle ich dringend, ausschließlich ein Standard-Benutzerkonto zu verwenden.
Hinweis: Jaguar sperrt sichere Systemeinstellungs-Bereiche nicht, wenn die Systemeinstellungen beendet werden. Sperre sichere Bereiche daher immer manuell. Wenn du das nicht tust, funktioniert der Exploit, bis du dich abmeldest.
Hinweis: Wenn du nicht zu einem Standard-Benutzerkonto wechseln kannst, könnte ein einfaches AppleScript, das sichere Systemeinstellungs-Bereiche als Anmeldeobjekt sperrt, die Aufgabe erfüllen.
Hinweis: Die normale Version von RootPipe Tester läuft nicht auf Jaguar. Lade die Legacy-Version von RootPipe Tester herunter, wenn du sie auf Jaguar ausführen möchtest.
Die Legacy-Version von RootPipe Tester ist in der Funktionalität mit der normalen Version gleichwertig, wird jedoch mit GCC 3.1 anstelle von GCC 4.0 kompiliert.
Testergebnisse:
Nicht verwundbar
Ein Exploit für Puma scheint machbar, da Puma dieselben Schritte zur Authentifizierung der Systemeinstellungen verwendet und die meisten notwendigen Komponenten vorhanden sind.
Das Einzige, was einen Exploit verhindert, ist, dass Puma nicht über SecurityFoundation.framework verfügt, das in späteren Versionen zur Autorisierung verwendet wird.
Stattdessen wird ein PrivateFramework namens NIInterface.framework verwendet, das zuerst per Reverse Engineering untersucht werden muss.
Gute Nachrichten trotzdem: Niemand wird Zeit darauf verwenden, eine wahrscheinlich so gut wie nicht vorhandene Nutzerbasis anzugreifen.
Zur Verbesserung der Sicherheit wird weiterhin empfohlen, ausschließlich ein Standard-Benutzerkonto zu verwenden und sichere Systemeinstellungs-Bereiche manuell zu sperren.
Hinweis: Nimm diesen Absatz mit Vorsicht. Ich habe mein Bestes getan, um herauszufinden, was wirklich vor sich geht, aber da es sich alles um PrivateFrameworks handelt, kann man nie zu 100 % wissen, was diese Methoden tun, erst recht nicht über so viele Versionen von Mac OS X hinweg, wie ich sie abzudecken versuche.
Die Funktionsweise des RootPipe-Exploits ist im Grunde dieselbe wie die der Systemeinstellungen beim Schreiben von Konfigurationsdateien (daher der Name WriteConfig), mit der Ausnahme, dass die Benutzer dieses Exploits nicht die Anwendung Systemeinstellungen sein müssen.
Bisher ist das nicht so schlimm, und eigentlich ist der gesamte Exploit auch nicht so schlimm.
Aber schauen wir uns den Code an.
// Authorization
SFAuthorization auth = [SFAuthorization authorization];
id authenticator = [Authenticator sharedAuthenticator];
[authenticator authenticateUsingAuthorizationSync:auth];
// Profit?
id sharedLiaison = [ToolLiaison sharedToolLiaison];
id tool = [sharedLiaison tool];
Wie du siehst, handelt es sich hier um Code im „alten Stil“, aber das Prinzip für den neuen Stil ist mehr oder weniger dasselbe.
Die ersten drei Zeilen in diesem Ausschnitt sind die Autorisierung, und die letzten beiden sind der eigentliche Spaß.
Wenn ein Systemeinstellungs-Bereich in den Systemeinstellungen Operationen ausführen muss, die privilegiert ausgeführt werden müssen, platziert er eine SFAuthorizationView (das Schlosssymbol) in der unteren linken Ecke. Diese SFAuthorizationView übernimmt dann die Erlangung und Zerstörung des Rechts system.preferences.
So weit, so gut, aber was ist dieses system.preferences?
Die Rechte, die Apple verwendet, und ihre Konfiguration haben sich im Laufe der Zeit geändert, aber das Prinzip ist dasselbe geblieben. Unten siehst du einen Auszug aus der Authorization Services Policy Database.
system.preferences auf 10.5.8
{
"allow-root" = 1;
class = user;
comment = "Checked by the Admin framework when making changes to certain System Preferences.";
group = admin;
shared = 1;
}
Wie du siehst, ist es ein geteiltes Recht. Das bedeutet, dass dieses Recht, sobald es von irgendeinem Prozess erlangt wurde, von jedem anderen Prozess genutzt werden kann, solange die Sitzung nicht zerstört wird (wenn du dich abmeldest).
Das ist für sich genommen nicht so schlimm, denn wenn eine Anwendung zum ersten Mal system.preferences verwenden möchte, musst du die Autorisierung erteilen. Leider autorisiert das System dieses Recht bei der Anmeldung automatisch (für Administrator-Benutzer).
Das bedeutet, dass unser RootPipe Tester nicht autorisiert werden muss und stattdessen die Autorisierung des Systems nutzen kann.
Standard-Benutzer sind sicher, weil das System das Recht system.preferences bei der Anmeldung nicht autorisiert.
Mit der ordnungsgemäß erlangten Autorisierung ist es ein ziemlich einfaches Spiel, Konfigurationsdateien (oder überhaupt jede andere Datei) mit beliebigen Rechten zu schreiben.
ToolLiaison richtet freudig ein NSDistantObject zu writeconfig für dich ein, und writeconfig wird die Datei freudig für dich schreiben, denn in ihren Augen hast du dich völlig ordnungsgemäß autorisiert.
Das Aktivieren des Kontrollkästchens „Passwort zum Entsperren jedes Systemeinstellungs-Bereichs verlangen“ in den Systemeinstellungen behebt das RootPipe-Problem auf allen Versionen von Mac OS X von 10.4 bis 10.8.
Das Aktivieren dieses Kontrollkästchens verändert das Recht system.preferences und setzt shared auf false.
Wenn ein Recht nicht geteilt wird, bedeutet das, dass jeder Prozess seine eigene Autorisierung einholen muss. Da die Erlangung einer Autorisierung erfordert, dass der Benutzer das Passwort eines Administrators eingibt, kann der Angriff vom Benutzer bemerkt werden.
Außerdem hat das bloße Ausführen von sudo denselben Effekt, was diesen Angriff nutzlos macht.
Nicht wirklich. Auf den ersten Blick könnte es wie eine aussehen, weil es sich in einem PrivateFramework befindet, das als root läuft und keine ordnungsgemäße Authentifizierung durchführt.
Aber das eigentliche Problem hier ist eher eines des schlechten Designs. Apple wollte sicherstellen, dass jeder Administrator-Benutzer die Möglichkeit hat, die Systemeinstellungen vollständig zu nutzen, und unter Unix alles eine Konfigurationsdatei braucht und diese geschrieben werden müssen (meistens als root).
Man könnte argumentieren, dass dies eine schlechte Idee ist (da würde ich zustimmen), aber ich würde es nicht als Backdoor betrachten, da die Authentifizierung ordnungsgemäß funktioniert und jeder Administrator ohnehin die Möglichkeit hat, über sudo root zu erlangen.
Das Hauptproblem hier ist, dass Apple Komfort über Sicherheit gestellt hat, aber das ist für sie auch nichts Besonderes.