{"id":106239,"date":"2022-12-22T15:36:49","date_gmt":"2022-12-22T13:36:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-systemd-coredump-pozvolyayushhaya-opredelit-soderzhimoe-pamyati-suid-programm"},"modified":"2022-12-22T15:36:49","modified_gmt":"2022-12-22T13:36:49","slug":"uyazvimost-v-systemd-coredump-pozvolyayushhaya-opredelit-soderzhimoe-pamyati-suid-programm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/uyazvimost-v-systemd-coredump-pozvolyayushhaya-opredelit-soderzhimoe-pamyati-suid-programm","title":{"rendered":"Sicherheitsanf\u00e4lligkeit in systemd-coredump, die es erm\u00f6glicht, den Inhalt des Speichers von suid-Programmen zu lesen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im Systemd-Coredump-Komponenten, die f\u00fcr die Verarbeitung von Core-Dateien verantwortlich ist, die nach einem pl\u00f6tzlichen Prozessabbruch generiert werden, wurde eine Schwachstelle (CVE-2022-4415) entdeckt. Diese erm\u00f6glicht es einem unprivilegierten lokalen Benutzer, den Inhalt des Speichers privilegierter Prozesse, die mit dem SUID-Root-Flag gestartet wurden, zu bestimmen. Das Problem mit der Standardkonfiguration wurde in den Distributionen openSUSE, Arch, Debian, Fedora und SLES best\u00e4tigt. <\/p>\n
Die Schwachstelle resultiert aus der fehlenden ordnungsgem\u00e4\u00dfen Verarbeitung des Sysctl-Parameters fs.suid_dumpable im Systemd-Coredump, der bei der standardm\u00e4\u00dfig auf 2 gesetzten Einstellung die Generierung von Core-Dumps f\u00fcr Prozesse mit SUID-Flag erlaubt. Es wird davon ausgegangen, dass die vom Kernel erstellten Core-Dateien von SUID-Prozessen Zugriffsrechte erhalten, die das Lesen nur f\u00fcr den Benutzer root zulassen. Das Systemd-Coredump-Tool, das vom Kernel zum Speichern von Core-Dateien aufgerufen wird, speichert die Core-Datei unter der ID root, gew\u00e4hrt jedoch zus\u00e4tzlich Zugriff auf die Core-Dateien basierend auf ACL, der das Lesen basierend auf der urspr\u00fcnglichen Prozess-ID erlaubt. <\/p>\n
Diese Funktion erm\u00f6glicht das Laden von Core-Dateien, ohne dass die Anwendung ihren Benutzeridentifikator \u00e4ndern und mit erh\u00f6hten Rechten ausgef\u00fchrt werden kann. Der Angriff besteht darin, dass ein Benutzer eine SUID-Anwendung starten und ihr ein SIGSEGV-Signal senden kann, um dann den Inhalt der Core-Datei zu laden, die einen Snapshot des Speicherprozesses w\u00e4hrend der abnormalen Beendigung enth\u00e4lt. <\/p>\n
Beispielsweise kann der Benutzer den Befehl «\/usr\/bin\/su» ausf\u00fchren und in einem anderen Terminal die Ausf\u00fchrung mit dem Befehl «kill -s SIGSEGV `pidof su`» beenden. Daraufhin speichert systemd-coredump die Core-Datei im Verzeichnis \/var\/lib\/systemd\/coredump und setzt eine ACL, die dem aktuellen Benutzer das Lesen erlaubt. Da das SUID-Tool ‘su’ den Inhalt von \/etc\/shadow in den Speicher liest, kann ein Angreifer auf die Hashes der Passw\u00f6rter aller Benutzer im System zugreifen. Das Tool sudo ist nicht anf\u00e4llig f\u00fcr solche Angriffe, da es die Erstellung von Core-Dateien durch ulimit verbietet. <\/p>\n
Laut den Entwicklern von systemd tritt die Schwachstelle ab der Version systemd 247 (November 2020) auf, jedoch ist auch die Version 246 betroffen, wie ein entdeckender Forscher berichtet. Die Schwachstelle zeigt sich, wenn systemd mit der Bibliothek libacl kompiliert wurde (dies ist standardm\u00e4\u00dfig in allen g\u00e4ngigen Distributionen der Fall). Ein Fix ist bisher nur als Patch verf\u00fcgbar. Die Nachverfolgung der Fixes in den Distributionen kann auf den folgenden Seiten erfolgen: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Gentoo, Arch. Eine vorl\u00e4ufige Schutzma\u00dfnahme besteht darin, den sysctl-Wert fs.suid_dumpable auf 0 zu setzen, was die \u00dcbertragung von Dumps an den systemd-coredump-Handler deaktiviert. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"