{"id":125693,"date":"2025-05-30T15:06:05","date_gmt":"2025-05-30T13:06:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-apport-i-systemd-coredump-pozvolyayushhie-izvlech-heshi-parolej-polzovatelej-sistemy"},"modified":"2025-05-30T15:06:05","modified_gmt":"2025-05-30T13:06:05","slug":"uyazvimosti-v-apport-i-systemd-coredump-pozvolyayushhie-izvlech-heshi-parolej-polzovatelej-sistemy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/uyazvimosti-v-apport-i-systemd-coredump-pozvolyayushhie-izvlech-heshi-parolej-polzovatelej-sistemy","title":{"rendered":"Sicherheitsl\u00fccken in apport und systemd-coredump erm\u00f6glichen das Extrahieren von Benutzerpasswort-Hashes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Unternehmen Qualys hat zwei Sicherheitsanf\u00e4lligkeiten 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\u00f6glicherweise zwischengespeicherte Anmeldeinformationen oder Verschl\u00fcsselungsschl\u00fcssel enthalten sind. Das Tool apport wird automatisch zur Speicherung von Core-Dumps in Ubuntu aufgerufen, w\u00e4hrend systemd-coredump in Red Hat Enterprise Linux 9+, Fedora und vielen anderen Linux-Distributionen verwendet wird. <\/p>\n
Die Angriffstechnik, die vorgestellt wurde, schafft Bedingungen f\u00fcr das unerwartete Beenden der SUID-Anwendung unix_chkpwd und damit den Zugriff auf die Core-Datei mit einem Zustandsdump w\u00e4hrend eines Absturzes. Der gespeicherte Core-Dump enthielt die Hashes der Benutzerpassw\u00f6rter, die im Speicher des abgest\u00fcrzten Prozesses verblieben waren, nachdem der Inhalt von \/etc\/shadow geladen wurde. Die M\u00f6glichkeit, die Schwachstellen auszunutzen, wurde in Ubuntu 24.04 und Fedora 40\/41 demonstriert, es wird jedoch angenommen, dass auch andere Distributionen anf\u00e4llig f\u00fcr \u00e4hnliche Angriffe sind. <\/p>\n
Beide Schwachstellen werden durch einen Wettlaufzustand verursacht, der es erm\u00f6glicht, den abgest\u00fcrzten SUID-Prozess durch einen anderen Prozess zu ersetzen, nachdem die Verarbeitung des Kernel-Absturzes begonnen hat, aber bevor der Handler im Benutzerspeicher die Prozessparameter \u00fcber \/proc\/pid\/files \u00fcberpr\u00fcft. Der Aufruf von apport und systemd-coredump erfolgt wie folgt: Der Kernel ruft die Informationen \u00fcber den Absturz des Prozesses ab und nennt den im Datei \/proc\/sys\/kernel\/core_pattern angegebenen Handler, der anschlie\u00dfend den Inhalt des Core-Dumps \u00fcber den Eingabestrom \u00fcbertr\u00e4gt. <\/p>\n
Die Generierung des Core-Dumps und der Start des Handlers erfolgen nicht sofort. Die daf\u00fcr ben\u00f6tigte 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\u00e4ren Benutzeranwendung aufgetreten ist und daher die Core-Datei mit Benutzerzugriffspeicherung, nicht nur f\u00fcr den Administrator, sichern. <\/p>\n
Der Angriff auf apport besteht aus folgenden Schritten: <\/p>\n
\n
Ein neuer Prozess wird abgezweigt, und die Funktion execve() wird aufgerufen, um ein SUID-Programm wie unix_chkpwd zu starten.\n
Es wird die Zeit \u00fcbersprungen, die ben\u00f6tigt 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).\n
Bevor der Befehl abgeschlossen ist, erh\u00e4lt der Prozess ein SIGSEGV- oder SIGSYS-Signal, um ihn sofort zu beenden.\n
Als Reaktion auf die sofortige Beendigung erstellt der Kernel einen Core-Dump und startet den apport-Prozess zur Verarbeitung des Core-Dumps im Benutzerspeicher.\n
Nach dem Start von apport, aber bevor der abgebrochene Prozess analysiert wird, erh\u00e4lt dieser das Signal SIGKILL, w\u00e4hrend der Prozess selbst durch einen anderen ohne das suid-Flag ersetzt wird. Um die \u00dcberpr\u00fcfungen in apport zu umgehen, wird der neue Prozess in separaten Namensr\u00e4umen (user, pid und mount namespace) erstellt.\n
apport verbindet sich mit dem Unix-Socket \/run\/apport.socket im w\u00e4hrend der Erstellung des neuen Prozesses geschaffenen Mount-Namespace und sendet einen Dateideskriptor f\u00fcr den Zugriff auf den Core-Dump. <\/ul>\n
Um f\u00fcr den neuen Prozess die ben\u00f6tigte Identifikation zu erhalten, die mit der Identifikation des suid-Prozesses \u00fcbereinstimmt, wird der suid-Prozess vor dem Senden des SIGSEGV-Signals mit dem Signal SIGSTOP gestoppt. W\u00e4hrend 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\u00e4lt 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. <\/p>\n
Was systemd-coredump betrifft, so ist es einerseits einfacher, einen Angriff darauf durchzuf\u00fchren, da es nicht erforderlich ist, den suid-Prozess durch einen Prozess in einem separaten Benutzerraum zu ersetzen, und es gen\u00fcgt, eine \u00dcbereinstimmung zwischen AT_UID und AT_EUID zu erreichen. Andererseits ist systemd-coredump in C geschrieben und startet relativ schnell, was weniger Zeit f\u00fcr die Manipulation bietet, im Gegensatz zu apport, das in Python geschrieben ist und w\u00e4hrend der Initialisierung verschiedene pyc-Dateien l\u00e4dt. Dieses Problem wird durch eine k\u00fcnstliche Verz\u00f6gerung von systemd-coredump gel\u00f6st \u2013 beim Aufruf einer suid-Datei werden eine sehr gro\u00dfe Anzahl von Befehlszeilenargumenten \u00fcbergeben, was die notwendige Verz\u00f6gerung w\u00e4hrend der Analyse von \/proc\/pid\/cmdline schafft. <\/p>\n
Im Rahmen der Analyse von Sicherheitsanf\u00e4lligkeiten haben Forscher ebenfalls festgestellt, dass systemd-coredump bei der Konfiguration des Aufrufs das Flag \u201e%d\u201c in \/proc\/sys\/kernel\/core_pattern nicht angibt, was es einem Angreifer erm\u00f6glicht, das Abbrechen von Hintergrundprozessen mit Root-Rechten zu initiieren, die andere Prozesse mit einer \u00c4nderung der Benutzer-ID auf einen nicht privilegierten Benutzer abzweigen. Diese M\u00f6glichkeit erlaubt es, nicht nur Angriffe auf setuid-Anwendungen durchzuf\u00fchren, sondern auch auf Prozesse wie sshd-session (OpenSSH), sd-pam (systemd) und cron, um vertrauliche Daten, die in ihrem Speicher liegen, wie private Schl\u00fcssel, Passwort-Hashes aus \/etc\/shadow, Canary-Tags aus dem Stack und Daten zur Umgehung der Adressraum-Randomisierung (ASLR) zu erlangen. <\/p>\n
Updates zu Paketver\u00f6ffentlichungen in den Distributionen k\u00f6nnen auf den Seiten von: Debian, Ubuntu, RHEL, openSUSE, Fedora, Gentoo und Arch verfolgt werden. Als Umgehung zur Blockierung von Sicherheitsanf\u00e4lligkeiten wird empfohlen, die Speicherung von Core-Dumps f\u00fcr SUID-Programme sowie f\u00fcr Prozesse, die Privilegien abgeben, zu deaktivieren, indem der Parameter \/proc\/sys\/fs\/suid_dumpable auf den Wert 0 gesetzt wird. Um das Problem vollst\u00e4ndig zu l\u00f6sen, sind \u00c4nderungen am Linux-Kernel erforderlich, um die \u00dcbertragung von Informationen \u00fcber abgest\u00fcrzte Prozesse \u00fcber den Mechanismus pidfd zu erm\u00f6glichen (pidfd ist an bestimmte Prozesse gebunden und wird im Gegensatz zu pid nicht neu zugewiesen). \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"