È stata scoperta una nuova vulnerabilità in Systemd

È stata rilevata una vulnerabilità in systemd che è già descritta in (CVE-2019-6454), di permette di bloccare il processo di inizializzazione del controllo (PID1) quando si invia un messaggio appositamente predisposto a un utente non privilegiato tramite D-Bus.

I Gli sviluppatori di Red Hat inoltre non escludono la possibilità di utilizzare la vulnerabilità per organizzare l'esecuzione del codice con privilegi di root., ma la possibilità finale di un simile attacco non è stata ancora determinata.

A proposito di systemd

Per chi non conosce Systemd Te lo posso dire questo è un sistema di inizializzazione Linux e gestore dei servizi che include funzionalità come l'avvio del demone su richiesta, il montaggio automatico e la manutenzione del punto di montaggio, il supporto delle istantanee e il monitoraggio dei processi utilizzando i gruppi di controllo Linux.

systemd fornisce un demone del registro e altri strumenti e utilità per aiutare con le comuni attività di amministrazione del sistema. Lennart Poettering e Kay Sievers hanno scritto SystemD, ispirato a macOS launchd e Upstart, con l'obiettivo di creare un sistema moderno e dinamico.

In particolare, systemd fornisce capacità di parallelizzazione aggressive e logica di controllo dei servizi basata sulle dipendenze, consentendo l'avvio dei servizi in parallelo e portando a tempi di avvio più rapidi. Questi due aspetti erano presenti in Upstart, ma migliorati da systemd.

Systemd è il sistema di avvio predefinito per le principali distribuzioni Linux, ma è retrocompatibile con gli script di avvio di SysV.

SysVinit è un sistema di inizializzazione che precede systemd e utilizza un approccio semplificato per avviare il servizio. Systemd non solo gestisce l'inizializzazione del sistema, ma fornisce anche alternative ad altre ben note utilità come cron e syslog.

Informazioni sulla nuova vulnerabilità di systemd

Manipolando la dimensione del messaggio inviato tramite D-Bus, un utente malintenzionato può spostare il puntatore oltre i limiti di memoria allocati per lo stack, bypassando la protezione di "stack guard-page", che si basa sulla sostituzione di una pagina di memoria al limite che chiama un'eccezione (page fault).

L'attacco riuscito è dimostrato su Ubuntu 18.10 con systemd 239 e su CentOS 7.6 con systemd 219.

Come soluzione alternativa, la compilazione può essere usata in GCC con l'opzione "-fstack-clash-protection", che è usata di default in Fedora 28 e 29.

Va notato che nel 2014 l'autore della libreria di sistema MUSL ha evidenziato tra i principali problemi architettonici il gestore PID1 di inflazione eccessiva di systemd e ha messo in dubbio la fattibilità di implementare un'API controller di livello PID1 per Link to the Bus, poiché è un vettore serio per attacchi e possono influire negativamente sull'affidabilità dell'intero sistema

Secondo un ricercatore di sicurezza who ha rivelato una vulnerabilità, una modifica del puntatore dello stack è possibile solo per le pagine di memoria inutilizzate (non assegnato), che non consente di organizzare l'esecuzione del codice nel contesto del processo PID1, ma consente a un utente malintenzionato di avviare il blocco PID1 con una successiva transizione del kernel Linux allo stato di "panico" a guasto del controller PID 1, l'intero sistema si blocca).

In systemd, è installato un gestore di segnali che cerca di intercettare gli errori del processo PID1 (errore di segmentazione) e avvia la shell per il ripristino.

Ma poiché, durante l'attacco, viene effettuata una chiamata a pagine di memoria non duplicate (non allocate), il kernel non può chiamare questo gestore di segnali e termina semplicemente il processo con PID 1, che a sua volta lo fa È impossibile continuare a lavorare ed entrare lo stato "panico", quindi è necessario riavviare il sistema.

C'è già una soluzione al problema

Come ogni problema di sicurezza già descritto e segnalato, la sua pubblicazione non può essere effettuata finché il problema non è stato risolto e aggiornamenti di patch di vulnerabilità per SUSE / openSUSE, Fedora sono già stati rilasciati, anche per Ubuntu e in parte per Debian (Solo Debian Stretch).
Sebbene il problema rimanga non corretto in RHEL.