Linus Torvalds ha accolto nel kernel un documento che regolamenta il processo di gestione degli errori legati alla sicurezza, definisce un modello di minacce, spiega quali errori nel kernel sono considerati vulnerabilità e analizza le azioni sugli errori identificati grazie all'AI. Il documento è stato redatto da Willy Tarreau, autore di HAProxy e sviluppatore di lungo corso del kernel Linux, che ha gestito il mantenimento di diversi rami stabili del kernel. Come base sono stati utilizzati gli accordi raggiunti durante la discussione delle recenti vulnerabilità critiche nel kernel (1, 2, 3, 4), rivelate prima della pubblicazione delle correzioni e per le quali, grazie all'AI, è stato possibile creare immediatamente exploit funzionanti.
Si prevede che la maggior parte degli errori di sicurezza venga gestita pubblicamente, per attrarre il più ampio pubblico possibile e trovare la soluzione ottimale. Solo i messaggi urgenti sulle vulnerabilità facilmente sfruttabili, che rappresentano una minaccia per molti utenti e consentono di ottenere privilegi o capacità estese, vengono proposti per invio a una lista di distribuzione privata.
Le vulnerabilità identificate con l'ausilio di assistenti AI vengono sempre discusse pubblicamente, poiché tali problemi vengono spesso scoperti simultaneamente da diversi ricercatori. In questo caso, non è necessario rivelare l'exploit nel rapporto — è sufficiente menzionare che è disponibile e fornire i dettagli in privato in risposta a una richiesta dell'accompagnatore.
Vengono descritte separatamente le regole per la trasmissione dei rapporti redatti con l'assistenza degli AI. Vengono inviati molti di questi rapporti e grazie a loro si riesce di tanto in tanto a identificare errori in parti di codice poco revisionate, ma gli accompagnatori tendono spesso a ignorarli a causa della bassa qualità e delle imprecisioni. I requisiti principali per i rapporti creati con l'assistenza dell'AI sono:
- Essere concisi, senza fronzoli e con l'indicazione del contenuto e dei dettagli importanti all'inizio.
- Solo testo semplice senza tag Markdown e decorazioni.
- Comprendere il modello di minacce e indicare i fatti verificabili (ad esempio, 'l'errore consente a qualsiasi utente di ottenere CAP_NET_ADMIN'), e non mere speculazioni o congetture sulle conseguenze della vulnerabilità.
- Prima di inviare il rapporto, è fondamentale testare accuratamente il funzionamento dell'exploit generato tramite AI e assicurarsi di poter riprodurre il problema.
- Coinvolgere l'AI per lo sviluppo e il collaudo della correzione del problema identificato.
Secondo le statistiche degli accompagnatori, la maggior parte dei rapporti sugli errori inviati come risoluzione delle vulnerabilità non lo è realmente e devono essere trattati come errori normali. Per separare le vulnerabilità dagli errori comuni è stata descritta una modello di minacce del kernel Linux. Tra le possibilità e garanzie, la cui violazione può essere considerata una vulnerabilità:
- 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 IPC e delle comunicazioni di rete.
- Protezione basata sulle capacità: 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 monitorare i processi di altri utenti.
- Lo spazio dei nomi degli identificatori degli utenti (CONFIG_USER_NS) consente agli utenti non privilegiati di creare i propri ambienti isolati, dai quali non è possibile influenzare l'ambiente globale, ad esempio modificando l'ora, caricando moduli e montando dispositivi a blocchi.
- Le interfacce di debug (/proc/kmsg, perf, debugfs), attraverso le quali è possibile accedere a informazioni riservate, sono disponibili solo dopo esplicita concessione di accesso da parte dell'amministratore.
Le capacità che non sono considerate vulnerabilità:
- Utilizzo di versioni obsolete del kernel.
- Compilazione con l'inclusione di opzioni per sviluppatori o riduttive per la sicurezza (ad esempio, CONFIG_NOMMU).
- Impostazioni sysctl non sicure, opzioni della riga di comando, permessi nel FS, capacità o concessione di accesso a interfacce privilegiate a utenti non privilegiati (ad esempio, accesso in scrittura a procfs e debugfs).
- Problemi nelle funzioni destinate esclusivamente allo sviluppo e al debug del kernel, come LOCKDEP, KASAN e FAULT_INJECTION, che non sono destinate a essere incluse nelle configurazioni di lavoro.
- Problemi nei driver, moduli e sottosistemi presenti nella sezione STAGING o contrassegnati come sperimentali, non sicuri o non funzionanti.
- Uso di moduli del kernel di terze parti o fork del kernel non ufficiali.
- Richiesta di privilegi eccessivi, come la necessità di eseguire azioni con diritti root o da parte di un utente con diritti 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 irrealistiche (ad esempio, sistemi con decine di migliaia di core CPU).
- Evasione dei meccanismi di protezione (ad esempio, ASLR) senza dimostrazione di exploit. Mancanza di controlli sugli argomenti e sul codice di errore restituito, privi di conseguenze evidenti.
- Fughe casuali di informazioni, fuori dal controllo degli aggressori, come dati residui nei messaggi di errore e fughe di indirizzi/puntatori della memoria del kernel senza possibilità diretta di sfruttamento.
- Errori nel montaggio di immagini disco danneggiate, se il driver non è dichiarato idoneo per l'uso con supporti non affidabili. Problemi con le immagini disco identificabili e risolvibili avviando l'utility fsck.
- Attacchi che richiedono accesso fisico all'hardware, modifica dell'hardware o collegamento di dispositivi hardware, come schede per attacchi DMA e analizzatori logici, se il sistema non è specificamente configurato per proteggersi contro tali attacchi (IOMMU).
- Regressioni nella funzionalità e nelle prestazioni, risolvibili configurando diritti e limiti.
Fonte: opennet.ru
