Rilascio del modulo LKRG 0.8 per la protezione contro lo sfruttamento delle vulnerabilità nel kernel Linux

Progetto Openwall ha pubblicato rilascio del modulo del kernel LKRG 0.8 (Linux Kernel Runtime Guard), progettato per rilevare e bloccare attacchi e violazioni dell'integrità delle strutture del kernel. Ad esempio, il modulo può proteggere contro modifiche non autorizzate del kernel in esecuzione e tentativi di alterare i privilegi dei processi utente (identificazione dell'uso di exploit). Il modulo è adatto sia per organizzare la protezione contro exploit noti per il kernel Linux (ad esempio, in situazioni in cui è problematico aggiornare il kernel), sia per contrastare exploit per vulnerabilità sconosciute. Codice del progetto distribuito è sotto licenza GPLv2.

Tra le modifiche nella nuova versione:

• È stato modificato il posizionamento del progetto LKRG, ora presentato come un prodotto unico per la rilevazione di attacchi e diverse violazioni dell'integrità, anziché diviso in sottosistemi separati per il controllo dell'integrità e l'identificazione di exploit;
• È stata garantita la compatibilità con i kernel Linux dalla versione 5.3 alla 5.7, così come con i kernel compilati con ottimizzazioni aggressive di GCC, senza le opzioni CONFIG_USB e CONFIG_STACKTRACE o con l'opzione CONFIG_UNWINDER_ORC, e anche con i kernel nei quali mancano le funzioni LKRG intercettate, se ciò è possibile;
• In fase di compilazione, è stato implementato un controllo di alcune impostazioni obbligatorie del kernel CONFIG_* per generare messaggi di errore significativi invece di crash poco chiari;
• Aggiunta la compatibilità con le modalità di sospensione (ACPI S3, suspend to RAM) e ibernazione (S4, suspend to disk);
• Supporto DKMS aggiunto nel Makefile;
• Implementato il supporto sperimentale per piattaforme ARM a 32 bit (testato su Raspberry Pi 3 Model B). Il supporto precedente per AArch64 (ARM64) è stato esteso per garantire compatibilità con la scheda Raspberry Pi 4;
• Aggiunti nuovi gestori (hook), compreso il gestore di chiamata capable() per migliorare l'identificazione di exploit che manipolano “capacità“, piuttosto che identificatori di processo (credentials);
• Proposta una nuova logica per identificare i tentativi di uscita dai vincoli degli spazi dei nomi (ad esempio, dai contenitori Docker);
• Nei sistemi x86-64 è garantito il controllo e l'applicazione del bit SMAP (Supervisor Mode Access Prevention), progettato per bloccare l'accesso ai dati nello spazio utente da codice privilegiato eseguito a livello di kernel. La protezione SMEP (Supervisor Mode Execution Prevention) è stata implementata in precedenza;
• Durante l'esecuzione, le impostazioni LKRG vengono allocate in una pagina di memoria normalmente accessibile solo in lettura;
• Il logging delle informazioni che possono essere più utili per gli attacchi (ad esempio, informazioni sugli indirizzi nel kernel) è limitato al livello di debug (log_level=4 e superiore), disabilitato di default.
• Incrementata la scalabilità del database di monitoraggio dei processi: invece di un solo albero RB protetto da uno spinlock, è stata utilizzata una tabella hash di 512 alberi RB, ciascuno protetto da 512 lock di lettura-scrittura;
• Implementato e abilitato per impostazione predefinita un modo in cui il controllo dell'integrità degli identificatori di processo viene di frequente eseguito solo per il compito attuale, e facoltativamente per i compiti attivati (che si risvegliano). Per gli altri compiti che si trovano in uno stato di sospensione o operano senza interagire con l'API controllata LKRG del kernel, il controllo viene eseguito con minore frequenza.
• Aggiunti nuovi parametri sysctl e opzioni del modulo per la messa a punto fine di LKRG, così come due sysctl per una configurazione semplificata scegliendo tra set di configurazioni dettagliate preparati dagli sviluppatori (profiles);
• Le impostazioni predefinite sono state modificate per raggiungere un miglior equilibrio tra prontezza nel rilevare le violazioni e l’efficacia della reazione da un lato, e impatto sulle prestazioni e rischio di falsi positivi dall’altro;
• Il file unit di systemd è stato rielaborato per caricare il modulo LKRG in una fase iniziale di avvio (per disabilitare il modulo può essere utilizzato un parametro della riga di comando del kernel);

Con le ottimizzazioni proposte nella nuova versione, il degrado delle prestazioni nell'uso di LKRG 0.8 è stimato attorno al 2,5% in modalità predefinita (“heavy”) e 2% in modalità leggera (“light”).

In un recente ricerca efficacia dei pacchetti per rilevare rootkit LKRG ha mostrato i migliori risultati, senza falsi positivi, hanno identificato 8 dei 9 rootkit testati, operanti a livello di kernel (sono stati rilevati rootkit come Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit e Sutekh, ma è stato omesso Keysniffer, che è un modulo kernel con keylogger, e non un rootkit nel senso stretto del termine). A titolo di confronto, i pacchetti AIDE, OSSEC e Rootkit Hunter hanno identificato 2 rootkit su 9, mentre Chkrootkit non ha identificato alcuno. Tuttavia, è importante notare che LKRG non supporta la rilevazione di rootkit posizionati nello spazio utente, quindi la massima efficacia si ottiene utilizzando la combinazione AIDE e LKRG, che ha effettuato il rilevamento di 14 dei 15 rootkit di tutti i tipi.

È possibile notare inoltre che lo sviluppatore della distribuzione Whonix ho iniziato è in fase di creazione pacchetti pronti con DKMS per Debian, Whonix, Qubes e Kicksecure, e il pacchetto per Arch Linux è già stato aggiornato alla versione 0.8. I pacchetti con LKRG sono anche disponibili in Russia. ALT Linux e Astra Linux.

La verifica dell'integrità in LKRG avviene confrontando il codice attuale e i dati del kernel e dei moduli, alcune importanti strutture dati e impostazioni della CPU con gli hash salvati o le copie delle aree di memoria, delle strutture dati o dei registri corrispondenti. Le verifiche vengono attivate sia periodicamente tramite timer che al verificarsi di vari eventi.

La determinazione di possibili exploit e il blocco degli attacchi avvengono prima che il kernel conceda accesso alle risorse (ad esempio, prima che un file venga aperto), ma dopo che un processo ha ottenuto permessi non autorizzati (ad esempio, cambiando l'UID). Quando viene rilevato un comportamento non autorizzato dei processi, questi vengono terminati forzatamente per impostazione predefinita, il che è sufficiente per bloccare molti exploit.

Fonte: opennet.ru