La radice dei metodi può essere utilizzata per elevarsi alla modalità kernel

Quando la maggior parte degli utenti Linux sente "root", pensa al massimo privilegio possibile su un computer. Alcuni pensano addirittura che root venga eseguito nell'anello 0. Ma in realtà, root è solo un utente normale che gira nell'anello 3, anche se il kernel si fida (molte operazioni sensibili del kernel sono protette con controlli lungo le linee di if (!uid_eq(current_uid(), GLOBAL_ROOT_UID)) return -EPERM; per prevenire l'abuso , che restituisce semplicemente un errore se uid != 0 ).

Sulla maggior parte dei sistemi Linux, il kernel si affida a root così tanto che può facilmente sfruttare il kernel e accedere a ring 0 a piacimento. Tuttavia, è spesso possibile con strumenti di sicurezza come grsecurity, SELinux, ecc, per prevenire ciò riducendo le abilità pericolose di root e applicando queste restrizioni a livello di kernel.

Vorrei enumerare una lista di metodi con cui root potrebbe sfruttare il kernel per accedere alla modalità kernel e fare il ring 0. Finora, questi sono i metodi che ho pensato o imparato da ciò che potrebbe accadere, insieme a potenziali attenuazioni:

• ioperm() e iopl() possono impostare i permessi delle porte I / O e possono essere abusati per scrivere in regioni arbitrarie di memoria, inclusa la memoria in cui risiede il kernel. Queste syscall possono essere disabilitate rimuovendole dalla tabella syscall o con grsecurity.
• Il root può semplicemente modificare l'immagine del kernel in /boot o attraverso il dispositivo a blocchi. Un MAC può limitare l'accesso di root a entrambi.
• /dev/{k,}mem sono progettati per consentire l'accesso rw alla memoria arbitraria. Questi possono essere disabilitati completamente nella configurazione del kernel, usando grsecurity, o con un MAC.
• Alcuni MSR possono essere utilizzati per scrivere in una memoria arbitraria. Negare la scrittura agli MSR disabilitandoli nella configurazione del kernel o con grsecurity attenua questo problema.
• kexec consente a root di selezionare un kernel alternativo da avviare. Questa è una funzionalità del kernel opzionale, quindi è sufficiente compilare il kernel senza il supporto di kexec per rendere questo un non-problema.
• sysfs fornisce un accesso di basso livello a gran parte dell'hardware, che può sequestrare un BIOS / UEFI difficilmente bloccato su molti sistemi vulnerabili per ottenere l'anello 0 o persino l'accesso ad anello -2. Un MAC può limitare l'accesso a /sys e vari strumenti possono rilevare vulnerabilità in UEFI / BIOS.
• Se a root è consentito caricare le tabelle ACPI in fase di esecuzione (DSDT, SSDT, ecc.), il kernel può eseguire AML, che è un bytecode ACPI e modificare il modo in cui il kernel si comporta e reagisce all'hardware su cui gira. So poco di ACPI e AML, ma suona come una ricetta assoluta per il disastro. La disabilitazione del supporto della tabella ACPI caricabile nel kernel dovrebbe attenuarlo.
• Il caricamento di moduli del kernel dannosi può dirottare direttamente il kernel. Questo può essere banalmente sconfitto richiedendo la firma del modulo o costruendo un kernel senza il supporto del modulo.

Ovviamente, userò il principio del privilegio minimo per root, piuttosto che cercare di inserire nella lista nera tutti i possibili modi in cui può uscire dalle sue catene. Ciò non cambia il fatto che sia ancora estremamente utile, e interessante , per comprendere tutti i modi in cui può abusare della fiducia del kernel.

E così questo mi porta alla mia domanda: ci sono altri metodi che la root può usare per ottenere l'accesso allo squillo 0, senza usare 0days e senza sfruttare gli errori opsec, che non ho trattato qui?