Die Firma Qualys hat zwei Schwachstellen in den Werkzeugen apport (CVE-2025-5054) und systemd-coredump (CVE-2025-4598) festgestellt, die zur Verarbeitung von Core-Dumps eingesetzt werden, die nach dem Absturz von Prozessen erzeugt werden. Die Schwachstellen ermöglichen den Zugriff auf Core-Dumps, die nach dem Absturz von SUID-Anwendungen oder bestimmten systemweiten Hintergrundprozessen gespeichert wurden, in deren Speicher möglicherweise zwischengespeicherte Anmeldedaten oder Verschlüsselungsschlüssel enthalten sind. Das Tool apport wird automatisch aufgerufen, um Core-Dumps in Ubuntu zu speichern, während systemd-coredump in Red Hat Enterprise Linux 9+, Fedora und vielen anderen Linux-Distributionen verwendet wird.
Eine Angriffstechnik wurde demonstriert, bei der Bedingungen für den Absturz der SUID-Anwendung unix_chkpwd geschaffen wurden, um Zugriff auf den Core-Dump mit dem Zustand während des Absturzes zu erhalten. Im gespeicherten Core-Dump waren Hashes der Benutzerpasswörter des Systems enthalten, die im Speicher des abgestürzten Prozesses verblieben, nachdem der Inhalt von /etc/shadow geladen wurde. Die Möglichkeit der Ausnutzung der Schwachstellen wurde in Ubuntu 24.04 und Fedora 40/41 demonstriert, es wird jedoch angenommen, dass auch andere Distributionen für ähnliche Angriffe anfällig sind.
Beide Schwachstellen werden durch einen Race Condition verursacht, der es ermöglicht, einen abgestürzten SUID-Prozess durch einen anderen Prozess zu ersetzen, genau nachdem das Kernel mit der Behandlung des Absturzes begonnen hat, jedoch bevor der Handler die Prozessparameter über /proc/pid/files im Benutzermodus überprüft. Der Aufruf von apport und systemd-coredump erfolgt wie folgt: Das Kernel erhält Informationen über den Absturz des Prozesses und ruft den im Datei /proc/sys/kernel/core_pattern angegebenen Handler auf, nachdem es ihm den Inhalt des Core-Dumps über den Eingabestrom überträgt.
Die Generierung des Core-Dumps und der Aufruf des Handlers erfolgt nicht sofort und es gibt genügend Zeit, um den abgestürzten SUID-Prozess durch einen normalen Benutzerprozess zu ersetzen. Im Falle einer Ersetzung wird der gestartete Handler für Core-Dumps annehmen, dass der Absturz nicht im SUID-Prozess, sondern in einer regulären Benutzeranwendung aufgetreten ist und wird dementsprechend die Core-Datei mit Zugangsmöglichkeiten für den normalen Benutzer speichern, anstatt nur für den Administrator.
Der Angriff auf apport umfasst folgende Schritte:
- Ein neuer Prozess wird abgezweigt und die Funktion execve() wird aufgerufen, um ein SUID-Programm wie unix_chkpwd zu starten.
- Es wird die Zeit übersprungen, die benötigt wird, um von der suid-Anwendung vertrauliche Daten in den Speicher zu laden (bei unix_chkpwd wird erwartet, dass die Hashes der Passwörter aller Systembenutzer aus der Datei /etc/shadow geladen werden).
- Vor dem Ende der Ausführung des Befehls wird dem Prozess das Signal SIGSEGV oder SIGSYS zum Notabschalten gesendet.
- Als Antwort auf den Notabschaltung erstellt der Kernel einen Core-Dump und startet den Prozess apport zur Verarbeitung des Core-Dumps im Benutzerspeicher.
- Nach dem Start von apport, aber bevor der abgestürzte Prozess analysiert wird, erhält er das Signal SIGKILL, und der Prozess wird durch einen anderen ohne das suid-Flag ersetzt. Um die Überprüfungen in apport zu umgehen, wird der neue Prozess innerhalb separater Namensräume (user, pid und mount namespace) erstellt.
- apport verbindet sich mit dem Unix-Socket /run/apport.socket im erstellten Namensraum des neuen Prozesses und sendet einen Dateideskriptor für den Zugriff auf den Core-Dump.
Um für den neuen Prozess die benötigte ID zu erhalten, die mit der ID des suid-Prozesses übereinstimmt, wird der suid-Prozess vor dem Senden des SIGSEGV-Signals mit SIGSTOP angehalten, und während dieser Zeit werden zyklisch neue Prozesse gestartet, bis eine PID mit einer vorhergehenden Nummer, die nahe der ersetzbaren suid-Process liegt, erhalten wird. Nach der Verschiebung der PID-Nummer werden dem suid-Prozess die Signale SIGSEGV und SIGCONT gesendet, danach wird SIGKILL gesendet und zyklisch neue Prozesse gestartet, um die gleiche PID wie der suid-Prozess zu erreichen.
Was systemd-coredump betrifft, so ist es einerseits einfacher, einen Angriff darauf durchzuführen, da es nicht erforderlich ist, den suid-Prozess durch einen Prozess in einem separaten Benutzerspeicher zu ersetzen, und es genügt, eine Übereinstimmung von AT_UID und AT_EUID zu erreichen. Andererseits ist systemd-coredump in C geschrieben und wird ausreichend schnell gestartet, was weniger Zeit für einen Austausch lässt, im Gegensatz zu apport, das in Python geschrieben ist und während der Initialisierung verschiedene pyc-Dateien lädt. Solch ein Problem wird durch künstliche Verzögerung von systemd-coredump gelöst – beim Aufruf der suid-Datei werden eine sehr große Anzahl von Befehlszeilen-Argumenten übergeben, was die erforderliche Verzögerung während der Analyse von /proc/pid/cmdline erzeugt.
Bei der Analyse von Sicherheitsanfälligkeiten haben die Forscher auch festgestellt, dass systemd-coredump beim Konfigurieren des Aufrufs das Flag „%d“ in /proc/sys/kernel/core_pattern nicht angibt. Dies ermöglicht es einem Angreifer, unprivilegierte Hintergrundprozesse, die mit Root-Rechten ausgeführt werden und andere Prozesse mit einem nicht privilegierten Benutzeridentifikator abspalten, durch einen Absturz zu aktivieren. Diese Möglichkeit erlaubt es, Angriffe nicht nur auf setuid-Anwendungen, sondern auch auf Prozesse wie sshd-session (OpenSSH), sd-pam (systemd) und cron durchzuführen, um vertrauliche Daten zu extrahieren, die in ihrem Speicher verbleiben, wie z. B. private Schlüssel, Passwort-Hashes aus /etc/shadow, Canary-Tags aus dem Stack und Daten zur Umgehung der Address Space Layout Randomization (ASLR).
Die Verfolgung von Paketaktualisierungen in den Distributionen kann auf den Seiten: Debian, Ubuntu, RHEL, openSUSE, Fedora, Gentoo, Arch erfolgen. Als Umgehung zur Blockierung von Sicherheitsanfälligkeiten wird empfohlen, das Speichern von Core-Dumps für suid-Programme und privilegierte Prozessrücksetzungen zu deaktivieren, indem der Parameter /proc/sys/fs/suid_dumpable auf den Wert 0 gesetzt wird. Für eine vollständige Behebung des Problems sind Änderungen am Linux-Kernel erforderlich, der die Möglichkeit implementiert, Informationen über einen abgestürzten Prozess über den pidfd-Mechanismus zu übermitteln (pidfd wird mit bestimmten Prozessen verknüpft und wird im Gegensatz zu pid nicht erneut zugewiesen).
Quelle: opennet.ru
