Vulnerabilità in apport e systemd-coredump che consentono di estrarre gli hash delle password degli utenti di sistema.

L'azienda Qualys ha identificato due vulnerabilità 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à 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.

È 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à di sfruttare le vulnerabilità è stata dimostrata su Ubuntu 24.04 e Fedora 40/41, ma si presume che anche altre distribuzioni siano vulnerabili a simili attacchi.

Entrambe le vulnerabilità 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.

La generazione del core dump e l'avvio dell'handler non avvengono istantaneamente ed è 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à che l'errore si sia verificato non nel processo suid, ma in un'applicazione utente normale e, di conseguenza, salverà il file core con accesso consentito all'utente normale, e non solo all'amministratore.

L'attacco a apport consiste nei seguenti passaggi:

  • Viene avviato un nuovo processo ed è chiamata la funzione execve() per lanciare un programma suid, come unix_chkpwd.
  • Viene atteso il tempo necessario affinché 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).
  • Prima che il comando venga completato, viene inviato al processo un segnale SIGSEGV o SIGSYS per la terminazione anomala.
  • 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.
  • 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 è creato all'interno di spazi dei nomi separati (user, pid e mount namespace).
  • 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.

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.

Per quanto riguarda systemd-coredump, da un lato l'esecuzione di un attacco su di esso è più semplice, poiché non è necessario sostituire il processo suid con un processo in uno spazio utente separato e basta raggiungere la corrispondenza tra AT_UID e AT_EUID. Dall'altro lato, systemd-coredump è scritto in C e viene avviato piuttosto rapidamente, il che fornisce meno tempo per la sostituzione, a differenza di apport, che è scritto in Python e durante l'inizializzazione carica diversi file .pyc. Questo problema viene risolto con un'introduzione artificiale di ritardo in systemd-coredump: quando si chiama il file suid, viene passato un numero molto elevato di argomenti della riga di comando, creando il ritardo necessario durante l'analisi di /proc/pid/cmdline.

Durante l'analisi delle vulnerabilità, i ricercatori hanno anche scoperto che systemd-coredump, quando configurato, non specifica nel /proc/sys/kernel/core_pattern il flag «%d», consentendo a un attaccante di causare un arresto anomalo dei processi in background eseguiti con diritti di root e che avviano altri processi cambiando l'identificativo utente in un utente non privilegiato sotto il quale avviene l'attacco. Questa possibilità permette di attaccare non solo le applicazioni setuid, ma anche processi come sshd-session (OpenSSH), sd-pam (systemd) e cron, per ottenere dati sensibili memorizzati nella loro memoria, come le chiavi private, gli hash delle password da /etc/shadow, i segni canarini dallo stack e i dati per eludere la randomizzazione dello spazio degli indirizzi (ASLR).

È 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à, 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à di trasmettere informazioni sui processi terminati in modo anomalo tramite il meccanismo pidfd (pidfd è legato a processi specifici e, a differenza di pid, non viene riassegnato).

Fonte: opennet.ru

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster