Das Unternehmen Qualys hat zwei Sicherheitsanfälligkeiten in den Tools apport (CVE-2025-5054) und systemd-coredump (CVE-2025-4598) entdeckt, die zur Verarbeitung von Core-Dateien verwendet werden, die nach dem unerwarteten Beenden von Prozessen generiert werden. Diese Schwachstellen erlauben den Zugriff auf Core-Dateien, die nach dem Absturz von SUID-Anwendungen oder bestimmten systeminternen Hintergrundprozessen gespeichert wurden, in deren Speicher möglicherweise zwischengespeicherte Anmeldeinformationen oder Verschlüsselungsschlüssel enthalten sind. Das Tool apport wird automatisch zur Speicherung von Core-Dumps in Ubuntu aufgerufen, während systemd-coredump in Red Hat Enterprise Linux 9+, Fedora und vielen anderen Linux-Distributionen verwendet wird.
Die Angriffstechnik, die vorgestellt wurde, schafft Bedingungen für das unerwartete Beenden der SUID-Anwendung unix_chkpwd und damit den Zugriff auf die Core-Datei mit einem Zustandsdump während eines Absturzes. Der gespeicherte Core-Dump enthielt die Hashes der Benutzerpasswörter, die im Speicher des abgestürzten Prozesses verblieben waren, nachdem der Inhalt von /etc/shadow geladen wurde. Die Möglichkeit, die Schwachstellen auszunutzen, wurde in Ubuntu 24.04 und Fedora 40/41 demonstriert, es wird jedoch angenommen, dass auch andere Distributionen anfällig für ähnliche Angriffe sind.
Beide Schwachstellen werden durch einen Wettlaufzustand verursacht, der es ermöglicht, den abgestürzten SUID-Prozess durch einen anderen Prozess zu ersetzen, nachdem die Verarbeitung des Kernel-Absturzes begonnen hat, aber bevor der Handler im Benutzerspeicher die Prozessparameter über /proc/pid/files überprüft. Der Aufruf von apport und systemd-coredump erfolgt wie folgt: Der Kernel ruft die Informationen über den Absturz des Prozesses ab und nennt den im Datei /proc/sys/kernel/core_pattern angegebenen Handler, der anschließend den Inhalt des Core-Dumps über den Eingabestrom überträgt.
Die Generierung des Core-Dumps und der Start des Handlers erfolgen nicht sofort. Die dafür benötigte Zeit reicht aus, um den beendeten SUID-Prozess durch einen normalen Benutzerprozess zu ersetzen. Im Falle eines Austausches wird der gestartete Core-Dump-Handler annehmen, dass der Fehler nicht im SUID-Prozess, sondern in einer regulären Benutzeranwendung aufgetreten ist und daher die Core-Datei mit Benutzerzugriffspeicherung, nicht nur für den Administrator, sichern.
Der Angriff auf apport besteht aus folgenden Schritten:
- 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 sensible Daten in den Speicher des SUID-Programms zu laden (bei unix_chkpwd wird erwartet, dass die Passwort-Hashes aller Systembenutzer aus der Datei /etc/shadow geladen werden).
- Bevor der Befehl abgeschlossen ist, erhält der Prozess ein SIGSEGV- oder SIGSYS-Signal, um ihn sofort zu beenden.
- Als Reaktion auf die sofortige Beendigung erstellt der Kernel einen Core-Dump und startet den apport-Prozess zur Verarbeitung des Core-Dumps im Benutzerspeicher.
- Nach dem Start von apport, aber bevor der abgebrochene Prozess analysiert wird, erhält dieser das Signal SIGKILL, während der Prozess selbst durch einen anderen ohne das suid-Flag ersetzt wird. Um die Überprüfungen in apport zu umgehen, wird der neue Prozess in separaten Namensräumen (user, pid und mount namespace) erstellt.
- apport verbindet sich mit dem Unix-Socket /run/apport.socket im während der Erstellung des neuen Prozesses geschaffenen Mount-Namespace und sendet einen Dateideskriptor für den Zugriff auf den Core-Dump.
Um für den neuen Prozess die benötigte Identifikation zu erhalten, die mit der Identifikation des suid-Prozesses übereinstimmt, wird der suid-Prozess vor dem Senden des SIGSEGV-Signals mit dem Signal SIGSTOP gestoppt. Während dieser Haltezeit werden zyklisch neue Prozesse gestartet, bis eine PID mit einer vorhergehenden Nummer, die dem zu ersetzenden suid-Prozess nahekommt, erhalten wird. Nach der Verschiebung der PID-Nummer erhält der suid-Prozess die Signale SIGSEGV und SIGCONT, gefolgt von SIGKILL, und zyklisch werden 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 notwendig ist, einen suid-Prozess durch einen Prozess in einem separaten Benutzerraum zu ersetzen; es genügt, eine Übereinstimmung von AT_UID und AT_EUID zu erreichen. Andererseits ist systemd-coredump in C geschrieben und startet relativ schnell, was weniger Zeit für einen Austausch bietet, im Gegensatz zu apport, das in Python geschrieben ist und während der Initialisierung verschiedene pyc-Dateien lädt. Ein solches Problem kann durch künstliche Verzögerung von systemd-coredump gelöst werden – beim Aufruf der suid-Datei werden eine sehr große Anzahl von Befehlszeilenargumenten übergeben, was die erforderliche Verzögerung während der Analyse von /proc/pid/cmdline erzeugt.
Im Rahmen der Analyse von Sicherheitsanfälligkeiten haben die Forscher auch festgestellt, dass systemd-coredump bei der Konfiguration des Aufrufs das Flag „%d“ in /proc/sys/kernel/core_pattern nicht angibt, was es einem Angreifer ermöglicht, ein unerwartetes Beenden von Hintergrundprozessen auszulösen, die mit Root-Rechten ausgeführt werden und andere Prozesse mit der Benutzer-ID eines unprivilegierten Benutzers abzuspalten, unter dem der Angriff erfolgt. Diese Möglichkeit erlaubt Angriffe nicht nur auf setuid-Anwendungen, sondern auch auf Prozesse wie sshd-session (OpenSSH), sd-pam (systemd) und cron, um in deren Speicher verbleibende vertrauliche Daten wie private Schlüssel, Passwort-Hashes aus /etc/shadow, Canary-Werte vom Stack und Daten zur Umgehung der Address Space Layout Randomization (ASLR) zu erhalten.
Updates zu Paketveröffentlichungen in den Distributionen können auf den Seiten von: Debian, Ubuntu, RHEL, openSUSE, Fedora, Gentoo und Arch verfolgt werden. Als Umgehung zur Blockierung von Sicherheitsanfälligkeiten wird empfohlen, die Speicherung von Core-Dumps für SUID-Programme sowie für Prozesse, die Privilegien abgeben, zu deaktivieren, indem der Parameter /proc/sys/fs/suid_dumpable auf den Wert 0 gesetzt wird. Um das Problem vollständig zu lösen, sind Änderungen am Linux-Kernel erforderlich, um die Übertragung von Informationen über abgestürzte Prozesse über den Mechanismus pidfd zu ermöglichen (pidfd ist an bestimmte Prozesse gebunden und wird im Gegensatz zu pid nicht neu zugewiesen).
Quelle: opennet.ru
