{"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\/it\/blog\/novosti-interneta\/uyazvimosti-v-apport-i-systemd-coredump-pozvolyayushhie-izvlech-heshi-parolej-polzovatelej-sistemy","title":{"rendered":"Vulnerabilit\u00e0 in apport e systemd-coredump che consentono di estrarre gli hash delle password degli utenti di sistema.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
L'azienda Qualys ha identificato due vulnerabilit\u00e0 negli strumenti apport (CVE-2025-5054) e systemd-coredump (CVE-2025-4598), utilizzati per la gestione dei core dump generati dopo la terminazione anomala dei processi. Queste vulnerabilit\u00e0 consentono l'accesso ai core dump salvati dopo la terminazione anomala di applicazioni suid o alcuni processi di sistema in background, che potrebbero contenere credenziali memorizzate nella cache o chiavi di crittografia. Lo strumento apport viene invocato automaticamente per salvare i core dump su Ubuntu, mentre systemd-coredump viene usato in Red Hat Enterprise Linux 9+, Fedora e molte altre distribuzioni Linux. <\/p>\n
\u00c8 stata dimostrata una tecnica di attacco che ha creato condizioni per la terminazione anomala dell'applicazione suid unix_chkpwd e ha consentito l'accesso al core dump allo stato durante il crash. Nel core dump salvato erano presenti hash delle password degli utenti di sistema, rimasti in memoria nel processo terminato in modo anomalo dopo il caricamento del contenuto di \/etc\/shadow. La possibilit\u00e0 di sfruttare le vulnerabilit\u00e0 \u00e8 stata dimostrata su Ubuntu 24.04 e Fedora 40\/41, ma si presume che anche altre distribuzioni siano vulnerabili a simili attacchi. <\/p>\n
Entrambe le vulnerabilit\u00e0 sono causate da una condizione di race, che consente di sostituire il processo suid appena terminato con un altro processo nel momento successivo all'inizio della gestione del crash da parte del kernel, ma prima della verifica dei parametri del processo da parte dell'handler nello spazio utente attraverso \/proc\/pid\/files. Il richiamo di apport e systemd-coredump avviene nel seguente modo: il kernel, dopo aver ricevuto informazioni sulla terminazione anomala del processo, invoca l'handler specificato nel file \/proc\/sys\/kernel\/core_pattern, dopo di che gli passa il contenuto del core dump tramite lo stream di input. <\/p>\n
La generazione del core dump e l'avvio dell'handler non avvengono istantaneamente ed \u00e8 sufficiente un intervallo di tempo per sostituire il processo suid terminato con un processo utente normale. In caso di sostituzione, l'handler dei core dump avviato riterr\u00e0 che l'errore si sia verificato non nel processo suid, ma in un'applicazione utente normale e, di conseguenza, salver\u00e0 il file core con accesso consentito all'utente normale, e non solo all'amministratore. <\/p>\n
L'attacco a apport consiste nei seguenti passaggi: <\/p>\n
\n
Viene avviato un nuovo processo ed \u00e8 chiamata la funzione execve() per lanciare un programma suid, come unix_chkpwd.\n
Viene atteso il tempo necessario affinch\u00e9 il programma suid carichi i dati riservati in memoria (nel caso di unix_chkpwd si attende il caricamento degli hash delle password di tutti gli utenti di sistema dal file \/etc\/shadow).\n
Prima che il comando venga completato, viene inviato al processo un segnale SIGSEGV o SIGSYS per la terminazione anomala.\n
In risposta alla terminazione anomala, il kernel genera un core dump e avvia il processo apport per la gestione del core dump nello spazio utente.\n
Dopo l'avvio di apport, ma prima dell'inizio dell'analisi, al processo terminato in modo anomalo viene inviato un segnale SIGKILL e il processo stesso viene sostituito con un altro senza flag suid. Per eludere i controlli in apport, il nuovo processo \u00e8 creato all'interno di spazi dei nomi separati (user, pid e mount namespace).\n
apport si connette al socket unix \/run\/apport.socket nello spazio dei nomi di mount creato per il nuovo processo e invia un descrittore di file per accedere al core dump. <\/ul>\n
Per ottenere per il nuovo processo l'ID necessario che corrisponda all'ID del processo suid, prima dell'invio del segnale SIGSEGV, il processo suid viene fermato con il segnale SIGSTOP e durante l'arresto vengono lanciati ciclicamente nuovi processi fino a ottenere un PID con numero precedente, vicino a quello del processo suid da sostituire. Dopo lo spostamento della numerazione PID, al processo suid vengono inviati i segnali SIGSEGV e SIGCONT, dopo di che viene inviato SIGKILL e vengono ciclicamente avviati nuovi processi per ottenere lo stesso PID di quello del processo suid. <\/p>\n
Per quanto riguarda systemd-coredump, da un lato \u00e8 pi\u00f9 semplice condurre un attacco su di esso, poich\u00e9 non \u00e8 necessario sostituire il processo suid con un processo in uno spazio utente separato e basta ottenere una corrispondenza tra AT_UID e AT_EUID. D'altra parte, systemd-coredump \u00e8 scritto in C e viene eseguito abbastanza rapidamente, il che offre meno tempo per la sostituzione, rispetto ad apport, che \u00e8 scritto in Python e durante l'inizializzazione carica vari file pyc. Un problema simile si risolve rallentando artificialmente systemd-coredump: quando viene invocato un file suid, viene passato un numero molto elevato di argomenti dalla riga di comando, il che crea il ritardo necessario che si verifica durante l'analisi di \/proc\/pid\/cmdline. <\/p>\n
Nel processo di analisi delle vulnerabilit\u00e0, i ricercatori hanno anche scoperto che systemd-coredump, durante la configurazione della chiamata, non specifica nel \/proc\/sys\/kernel\/core_pattern il flag \u00ab%d\u00bb, il che consente all'attaccante di forzare l'arresto anomalo di processi in background eseguiti con diritti di root che avviano altri processi modificando l'identificatore utente a un utente non privilegiato sotto il quale viene effettuato l'attacco. Questa possibilit\u00e0 permette di attaccare non solo le applicazioni setuid, ma anche processi come sshd-session (OpenSSH), sd-pam (systemd) e cron, per ottenere dati riservati presenti nella loro memoria, come chiavi private, hash delle password da \/etc\/shadow, marcatori canarini dallo stack e dati per bypassare la randomizzazione dello spazio degli indirizzi (ASLR). <\/p>\n
\u00c8 possibile monitorare la pubblicazione degli aggiornamenti dei pacchetti nelle distribuzioni sulle pagine: Debian, Ubuntu, RHEL, openSUSE, Fedora, Gentoo, Arch. Come soluzione per bloccare le vulnerabilit\u00e0, si suggerisce di disabilitare il salvataggio dei core dump per i programmi suid e per i processi che elevano i privilegi, impostando il parametro \/proc\/sys\/fs\/suid_dumpable a 0. Per risolvere completamente il problema, sono necessarie modifiche al kernel Linux che implementano la capacit\u00e0 di trasmettere informazioni sui processi terminati in modo anomalo tramite il meccanismo pidfd (pidfd \u00e8 legato a processi specifici e, a differenza di pid, non viene riassegnato). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"