Modello di minacce e caratteristiche della valutazione delle vulnerabilità nel kernel Linux

Linus Torvalds ha incluso nel kernel un documento che regola il processo di gestione degli errori relativi alla sicurezza, definendo il modello delle minacce e spiegando quali errori nel kernel sono considerati vulnerabilità, trattando le azioni da intraprendere con gli errori identificati tramite AI. Il documento è stato redatto da Willy Tarreau, autore di HAProxy e da lungo tempo sviluppatore del kernel Linux, responsabile della manutenzione di diversi rami stabili del kernel. Come base, sono stati utilizzati gli accordi raggiunti durante le discussioni su recenti vulnerabilità critiche nel kernel (1, 2, 3, 4), rivelate prima della pubblicazione delle correzioni e per le quali, grazie all'AI, è stato possibile generare immediatamente exploit funzionanti.

La maggior parte degli errori associati alla sicurezza deve essere gestita pubblicamente, al fine di coinvolgere il pubblico più ampio possibile e trovare la soluzione ottimale. Solo le comunicazioni urgenti riguardanti vulnerabilità facilmente sfruttabili, che rappresentano una minaccia per molti utenti e che consentono di ottenere privilegi o capacità estesi, devono essere inviate a un elenco di distribuzione privato.

Le vulnerabilità identificate con l'ausilio di assistenti AI devono sempre essere discusse pubblicamente, poiché tali problemi vengono spesso scoperti contemporaneamente da più ricercatori. Tuttavia, non è necessario rivelare l'exploit nel rapporto; è sufficiente menzionare che è disponibile e fornirlo privatamente in risposta a una richiesta del revisore.

Le regole per la consegna dei rapporti generati con assistenti AI sono descritte separatamente. Vengono ricevuti molti rapporti di questo tipo e grazie a essi si riesce occasionalmente a identificare errori in parti di codice poco revisionate, ma i revisori spesso li ignorano a causa della bassa qualità e delle imprecisioni. I requisiti principali per i rapporti generati con il contributo dell'AI sono:

• Sintesi, senza fronzoli e con l'indicazione della sostanza e dei dettagli importanti all'inizio.
• Solo testo semplice senza tag Markdown e decorazioni.
• Comprensione del modello di minaccia e indicazione dei fatti da verificare (ad esempio, 'l'errore consente a qualsiasi utente di ottenere CAP_NET_ADMIN'), piuttosto che congetture teoriche e supposizioni sulle conseguenze della vulnerabilità.
• Prima di inviare il rapporto, è fondamentale testare a fondo il funzionamento dell'exploit generato tramite AI e assicurarsi di poter riprodurre il problema.
• Coinvolgere l'AI per lo sviluppo e il test della correzione del problema identificato.

Secondo le statistiche degli accompagnatori, la maggior parte dei rapporti di errore inviati come risoluzioni delle vulnerabilità non lo sono realmente e devono essere trattati come normali errori. Per distinguere tra vulnerabilità e errori normali è stato descritto un modello di minaccia del kernel Linux. Tra le possibilità e le garanzie la cui violazione può essere considerata una vulnerabilità ci sono:

• Isolamento a livello utente: accesso ai file solo per il proprietario, la memoria del processo non è accessibile ad altri utenti, ptrace è vietato per i processi di altri, isolamento della IPC e delle comunicazioni di rete.
• Protezione basata su capabilities: senza CAP_SYS_ADMIN non è possibile modificare la configurazione del kernel, la memoria, lo stato del sistema; senza CAP_NET_ADMIN non è possibile modificare le impostazioni di rete o intercettare il traffico; senza CAP_SYS_PTRACE non è possibile tracciare i processi di altri utenti.
• Lo spazio dei nomi degli identificatori utente (CONFIG_USER_NS) consente agli utenti non privilegiati di creare i propri ambienti isolati, dai quali non è possibile influenzare lo spazio dei nomi globale, ad esempio, modificare l'orario, caricare moduli e montare dispositivi a blocchi.
• Le interfacce di debug (/proc/kmsg, perf, debugfs), attraverso le quali è possibile accedere a informazioni sensibili, sono disponibili solo dopo un'esplicita concessione di accesso da parte dell'amministratore.

Capacità che non sono considerate vulnerabilità:

• Utilizzo di versioni obsolete del kernel.
• Compilazione con l'attivazione di opzioni per sviluppatori o che riducono la sicurezza (ad esempio, CONFIG_NOMMU).
• Impostazione di configurazioni sysctl insicure, opzioni della riga di comando, diritti di accesso nel FS, capabilities o apertura di accesso a interfacce privilegiate per utenti non privilegiati (ad esempio, accesso in scrittura a procfs e debugfs).
• Problemi nelle funzioni destinate solo allo sviluppo e al debug del kernel, come LOCKDEP, KASAN e FAULT_INJECTION, che non sono destinate ad essere incluse nelle configurazioni di produzione.
• Problemi nei driver, nei moduli e nei sottosistemi nella sezione STAGING o contrassegnati come sperimentali, non sicuri o non funzionanti.
• Utilizzo di moduli del kernel di terze parti o fork non ufficiali del kernel.
• Richiesta di privilegi eccessivi, come la necessità di eseguire azioni con i diritti di root o da un utente con privilegi CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO e CAP_SYS_MODULE.
• Attacchi teorici che richiedono condizioni di laboratorio, miliardi di tentativi, emulazione o modifica dell'hardware, costi sproporzionati e configurazioni non realistiche (ad esempio, sistemi con decine di migliaia di core CPU).
• Elusione dei meccanismi di protezione (ad esempio, ASLR) senza dimostrazione di exploit. Assenza di controlli sugli argomenti e sui codici di errore restituiti, senza conseguenze ovvie.
• Fughe di informazioni casuali, non controllabili dagli aggressori, come dati residui nei messaggi di errore e fughe di indirizzi/punteri della memoria del kernel senza possibilità diretta di sfruttamento.
• Errori nel montaggio di immagini disco danneggiate, se il driver non è dichiarato come idoneo per l'uso con supporti non affidabili. Problemi con le immagini disco identificati e risolti tramite l'esecuzione dell'utilità fsck.
• Attacchi che richiedono accesso fisico all'hardware, modifica dell'hardware o connessione di dispositivi hardware, come schede per attacchi DMA e analizzatori logici, se il sistema non è specificamente configurato per difendersi da tali attacchi (IOMMU).
• Regressioni nella funzionalità e nelle prestazioni risolvibili tramite la configurazione dei diritti e dei limiti.

Fonte: opennet.ru