Progetto Openwall rilascio del modulo del kernel (Linux Kernel Runtime Guard), progettato per identificare e bloccare attacchi e violazioni dell'integrità delle strutture del kernel. Ad esempio, il modulo può proteggere da modifiche non autorizzate al kernel in esecuzione e tentativi di modifica dei privilegi dei processi utente (definizione dell'applicazione degli exploit). Il modulo è adatto sia per attuare protezioni contro exploit già noti per il kernel Linux (ad esempio, in situazioni in cui è difficile aggiornare il kernel), sia per resistere a exploit per vulnerabilità ancora sconosciute. Codice del progetto è sotto licenza GPLv2.
Tra le novità nella nuova versione:
- È cambiato il posizionamento del progetto LKRG, che ora non è suddiviso in singoli sottosistemi per il controllo dell'integrità e la definizione dell'applicazione degli exploit, ma viene presentato come un prodotto unificato per l'identificazione di attacchi e varie violazioni dell'integrità;
- È 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 opzioni CONFIG_USB e CONFIG_STACKTRACE o con l'opzione CONFIG_UNWINDER_ORC, oltre a kernel dai quali mancano le funzioni LKRG intercettate, se è possibile farne a meno;
- Durante la compilazione è stata garantita la verifica di alcune impostazioni obbligatorie del kernel CONFIG_* per fornire messaggi di errore significativi anziché guasti poco chiari;
- È stato aggiunto il supporto per le modalità di sospensione (ACPI S3, sospensione su RAM) e ibernazione (S4, sospensione su disco);
- È stato aggiunto il supporto per DKMS nel Makefile;
- È stato implementato il supporto sperimentale per piattaforme ARM a 32 bit (testato su Raspberry Pi 3 Model B). Il supporto precedente per AArch64 (ARM64) è stato ampliato per garantire la compatibilità con la scheda Raspberry Pi 4;
- Sono stati aggiunti nuovi gestori (hook), inclusa la gestione della chiamata capable() per una migliore identificazione degli exploit che manipolano ««, e non gli identificatori dei processi ();
- È stata proposta una nuova logica per identificare i tentativi di uscita dai vincoli degli spazi dei nomi (ad esempio, dai container Docker);
- Sui sistemi x86-64 è stata garantita la verifica 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) era già stata implementata in precedenza;
- Durante il funzionamento è stata garantita la collocazione delle impostazioni LKRG in una pagina di memoria normalmente accessibile solo in lettura;
- L'output nei log delle informazioni che possono essere più utili per gli attacchi (ad esempio, informazioni sugli indirizzi nel kernel) è limitato alla modalità di debug (log_level=4 e superiore), disabilitata per impostazione predefinita.
- Aumentata la scalabilità del DB di tracciamento dei processi: invece di un singolo albero RB protetto da un solo spinlock, viene utilizzata una tabella hash di 512 alberi RB, protetti da altrettanti 512 lock di lettura-scrittura;
- Implementata e attivata per impostazione predefinita una modalità in cui il controllo dell'integrità degli identificatori di processo viene spesso eseguito solo per il compito corrente, oltre che opzionalmente per i compiti attivati (in risveglio). Per gli altri compiti, in stato di sonno o in esecuzione senza accedere all'API LKRG controllata del kernel, il controllo viene eseguito con minore frequenza.
- Aggiunti nuovi sysctl e parametri del modulo per la configurazione fine di LKRG, e due sysctl per semplificare la configurazione attraverso la scelta tra set di parametri ottimizzati forniti dagli sviluppatori (profiles);
- Le impostazioni predefinite sono state modificate per ottenere un equilibrio più ponderato tra la reattività nella rilevazione delle violazioni e l'efficacia della risposta da una parte e l'impatto sulle prestazioni e il rischio di falsi positivi dall'altra;
- Il file unit systemd è stato riprogettato per caricare il modulo LKRG in una fase iniziale dell'avvio (per disabilitare il modulo può essere utilizzato il parametro della riga di comando del kernel);
Considerate le ottimizzazioni proposte nel nuovo rilascio, la diminuzione delle prestazioni con LKRG 0.8 è stimata attorno al 2.5% in modalità predefinita («heavy») e al 2% in modalità leggera («light»).
Nella recente esecuzione efficacia dei pacchetti per la rilevazione dei rootkit LKRG i migliori risultati, senza falsi positivi, identificando 8 dei 9 rootkit testati operanti a livello di kernel (sono stati individuati i rootkit Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit e Sutekh, ma è stato trascurato Keysniffer, che è un modulo del kernel con un 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 ne ha identificato alcuno. Tuttavia, LKRG non supporta la rilevazione dei rootkit posizionati nello spazio utente, quindi la massima efficacia si ottiene utilizzando la combinazione AIDE e LKRG, che ha consentito di identificare 14 dei 15 rootkit di tutti i tipi.
Inoltre, si può notare che il sviluppatore della distribuzione ha iniziato ha messo a disposizione pacchetti con DKMS per Debian, Whonix, Qubes e Kicksecure, mentre il pacchetto per è già stato aggiornato alla versione 0.8. I pacchetti con LKRG sono anche disponibili in Russia e .
Il controllo dell'integrità in LKRG avviene attraverso il confronto tra il codice e i dati attuali del kernel e dei moduli, alcune strutture dati e impostazioni CPU importanti con hash salvati o copie delle corrispondenti aree di memoria, strutture dati o registri. I controlli vengono attivati sia periodicamente tramite timer, sia al verificarsi di vari eventi.
La determinazione di possibili exploit e il blocco degli attacchi avviene in fase precedente alla concessione da parte del kernel di accesso alle risorse (ad esempio, prima dell'apertura di un file), ma dopo che il processo ha ottenuto autorizzazioni non autorizzate (ad esempio, cambiamento di UID). Se viene rilevato un comportamento non autorizzato dei processi, per impostazione predefinita viene eseguita la loro chiusura forzata, sufficiente a bloccare molti exploit.
Fonte: opennet.ru
