Progetto OpenWall rilascio del modulo del kernel (Linux Kernel Runtime Guard), progettato per rilevare 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 modificare le autorizzazioni dei processi utente (rilevando l'uso di exploit). Il modulo è adatto sia per organizzare la protezione contro gli exploit già noti per il kernel Linux (ad esempio, in situazioni in cui è difficile aggiornare il kernel nel sistema), sia per contrastare gli exploit per vulnerabilità ancora sconosciute. Codice del progetto concesso in licenza con GPLv2.
Tra le novità della nuova versione:
- È stato modificato il posizionamento del progetto LKRG, che non è più suddiviso in sottosistemi separati per il controllo dell'integrità e la determinazione dell'utilizzo degli exploit, ma si presenta come un prodotto completo per l'identificazione di attacchi e varie violazioni dell'integrità;
- Viene fornita la compatibilità con i kernel Linux da 5.3 a 5.7, così come con kernel compilati con ottimizzazioni GCC aggressive, senza le opzioni CONFIG_USB e CONFIG_STACKTRACE o con l'opzione CONFIG_UNWINDER_ORC, così come con kernel che non hanno funzioni agganciate LKRG, se possono essere dispensato;
- Durante la compilazione, vengono controllate alcune impostazioni obbligatorie del kernel CONFIG_* per generare messaggi di errore significativi invece di crash oscuri;
- Aggiunto supporto per le modalità standby (ACPI S3, sospensione su RAM) e sospensione (S4, sospensione su disco);
- Aggiunto supporto DKMS a Makefile;
- È stato implementato il supporto sperimentale per le piattaforme ARM a 32 bit (testato su Raspberry Pi 3 Modello B). Il supporto AArch64 (ARM64) precedentemente disponibile è stato ampliato per fornire compatibilità con la scheda Raspberry Pi 4;
- Sono stati aggiunti nuovi hook, incluso un gestore di chiamate able() per identificare meglio gli exploit che manipolano "", non gli ID di processo ();
- È stata proposta una nuova logica per rilevare i tentativi di sfuggire alle restrizioni dello spazio dei nomi (ad esempio, dai contenitori Docker);
- Sui sistemi x86-64, viene controllato e applicato il bit SMAP (Supervisor Mode Access Prevention), progettato per bloccare l'accesso ai dati dello spazio utente dal codice privilegiato in esecuzione a livello del kernel. La protezione SMEP (Supervisor Mode Execution Prevention) era implementata in precedenza;
- Durante il funzionamento, le impostazioni dell'LKRG vengono poste in una pagina di memoria che solitamente è di sola lettura;
- Le informazioni di registrazione che potrebbero essere più utili per gli attacchi (ad esempio, informazioni sugli indirizzi nel kernel) sono limitate alla modalità di debug (log_level=4 e superiore), che è disabilitata per impostazione predefinita.
- La scalabilità del database di tracciamento dei processi è stata aumentata: invece di un albero RB protetto da uno spinlock, viene utilizzata una tabella hash di 512 alberi RB protetti da 512 blocchi di lettura-scrittura;
- È stata implementata e abilitata per impostazione predefinita una modalità in cui l'integrità degli identificatori di processo viene spesso verificata solo per l'attività corrente e, facoltativamente, anche per le attività attivate (risveglio). Per altre attività che sono in stato di sospensione o che funzionano senza accedere all'API del kernel controllata da LKRG, il controllo viene eseguito meno frequentemente.
- Aggiunti nuovi parametri sysctl e modulo per la regolazione fine di LKRG, nonché due sysctl per una configurazione semplificata selezionando da set di impostazioni di regolazione fine (profili) preparati dagli sviluppatori;
- Sono state modificate le impostazioni predefinite per raggiungere un equilibrio più equilibrato tra velocità di rilevamento delle violazioni ed efficacia della risposta, da un lato, e impatto sulle performance e rischio di falsi positivi, dall’altro;
- Il file unit systemd è stato riprogettato per caricare il modulo LKRG all'inizio dell'avvio (è possibile utilizzare un'opzione della riga di comando del kernel per disabilitare il modulo);
Tenendo conto delle ottimizzazioni proposte nella nuova versione, la riduzione delle prestazioni quando si utilizza LKRG 0.8 è stimata al 2.5% in modalità predefinita (“heavy”) e al 2% in modalità leggera (“light”).
In una recente tenuta efficacia dei pacchetti per il rilevamento dei rootkit LKRG migliori risultati, identificando 8 rootkit su 9 testati che funzionano a livello di kernel senza falsi positivi (sono stati identificati i rootkit Diamorfine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit e Sutekh, ma Keysniffer, che è un kernel modulo, è mancato con un keylogger, non con un rootkit in senso letterale). Per fare un confronto, i pacchetti AIDE, OSSEC e Rootkit Hunter hanno rilevato 2 rootkit su 9, mentre Chkrootkit non ne ha rilevato nessuno. Allo stesso tempo, LKRG non supporta il rilevamento dei rootkit situati nello spazio utente, quindi la massima efficienza si ottiene quando si utilizza una combinazione di AIDE e LKRG, che ha permesso di identificare 14 rootkit su 15 di tutti i tipi.
Inoltre, si può notare che lo sviluppatore della distribuzione iniziato pacchetti già pronti con DKMS per Debian, Whonix, Qubes e Kicksecure e un pacchetto per già aggiornato alla versione 0.8. I pacchetti con LKRG sono disponibili anche in russo и .
Il controllo dell'integrità in LKRG viene eseguito confrontando il codice e i dati effettivi del kernel e dei moduli, alcune importanti strutture dati e le impostazioni della CPU con gli hash memorizzati o le 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 del possibile utilizzo di exploit e il blocco degli attacchi viene effettuato nella fase precedente a quella in cui il kernel fornisce l'accesso alle risorse (ad esempio, prima dell'apertura di un file), ma dopo che il processo ha ricevuto autorizzazioni non autorizzate (ad esempio, la modifica dell'UID). Quando viene rilevato un comportamento non autorizzato, i processi vengono forzati a terminare per impostazione predefinita, il che è sufficiente per bloccare molti exploit.
Fonte: opennet.ru