L'azienda Qualys ha individuato due vulnerabilit\u00e0 negli strumenti apport (CVE-2025-5054) e systemd-coredump (CVE-2025-4598), utilizzati per gestire i core dump generati dopo il crash dei processi. Le vulnerabilit\u00e0 consentono di accedere ai core dump salvati dopo il crash di applicazioni suid o di alcuni processi di sistema in background, la cui memoria potrebbe contenere credenziali memorizzate o chiavi di crittografia. Lo strumento apport viene automaticamente attivato per salvare i core dump in Ubuntu, mentre systemd-coredump \u00e8 utilizzato in Red Hat Enterprise Linux 9+, Fedora e in molte altre distribuzioni Linux. <\/p>\n
\u00c8 stata dimostrata una tecnica di attacco in cui sono state create condizioni per il crash dell'applicazione suid unix_chkpwd e per accedere al core dump dello stato durante il crash. Nel core dump salvato erano presenti gli hash delle password degli utenti del sistema, rimasti in memoria dopo che il processo era andato in crash, a seguito del caricamento del contenuto di \/etc\/shadow. La possibilit\u00e0 di sfruttare queste vulnerabilit\u00e0 \u00e8 stata dimostrata in Ubuntu 24.04 e Fedora 40\/41, ma si presume che altre distribuzioni siano vulnerabili a simili attacchi. <\/p>\n
Entrambe le vulnerabilit\u00e0 sono causate da una condizione di competizione che consente di sostituire il processo suid andato in crash con un altro processo nel momento immediatamente dopo l'inizio della gestione del crash da parte del kernel, ma prima che il gestore controlli i parametri del processo nello spazio utente tramite \/proc\/pid\/files. La chiamata a apport e systemd-coredump si effettua come segue: il kernel, dopo aver ricevuto l'informazione sul crash del processo, invoca il gestore specificato nel file \/proc\/sys\/kernel\/core_pattern, trasferendo quindi il contenuto del core dump attraverso il flusso di input. <\/p>\n
La generazione del core dump e l'avvio del gestore non avvengono istantaneamente e questo tempo \u00e8 sufficiente per sostituire il processo suid andato in crash con un normale processo utente. In caso di sostituzione, il gestore dei core dump avviato penser\u00e0 che il crash sia avvenuto non in un processo suid, ma in un'applicazione utente normale e, di conseguenza, salver\u00e0 il core file con accessibilit\u00e0 per un utente normale, e non solo per l'amministratore. <\/p>\n
L'attacco a apport si articola nei seguenti passaggi: <\/p>\n
Per ottenere per il nuovo processo il necessario identificatore che corrisponde all'identificatore del processo suid, prima di inviare il segnale SIGSEGV, il processo suid viene fermato con il segnale SIGSTOP e durante la pausa vengono avviati ciclicamente nuovi processi fino a ottenere un PID con un numero precedente, vicino a quello del processo suid da sostituire. Dopo lo spostamento della numerazione PID, ai segnali SIGSEGV e SIGCONT viene inviato il processo suid, dopo di che viene inviato SIGKILL e ciclicamente vengono avviati nuovi processi per raggiungere lo stesso PID del processo suid. <\/p>\n
Per quanto riguarda systemd-coredump, da un lato l'esecuzione di un attacco contro di esso \u00e8 pi\u00f9 semplice, 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. Dall'altro lato, systemd-coredump \u00e8 scritto in linguaggio C e viene eseguito abbastanza rapidamente, il che offre meno tempo per la sostituzione, a differenza di apport, che \u00e8 scritto in Python e carica vari file pyc durante il processo di inizializzazione. Questo problema pu\u00f2 essere risolto artificialmente rallentando systemd-coredump \u2014 quando si chiama un file suid, viene passato un numero molto elevato di argomenti da riga di comando, creando la necessaria latenza che si verifica durante l'analisi di \/proc\/pid\/cmdline. <\/p>\n
Durante l'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 '%d', il che consente all'attaccante di forzare l'arresto di processi in background eseguiti con diritti root e che forkano altri processi, modificando l'identificativo utente in un utente non privilegiato sotto il quale viene effettuato l'attacco. Tale possibilit\u00e0 consente di attuare un attacco non solo su applicazioni setuid, ma anche su processi come sshd-session (OpenSSH), sd-pam (systemd) e cron, per acquisire dati riservati che possono essere presenti nella loro memoria, come chiavi private, hash delle password da \/etc\/shadow, etichette canarino dallo stack e dati per bypassare la randomizzazione dell'indirizzamento (ASLR). <\/p>\n