Le vulnerabilità nel kernel stesso, sebbene serie, sono solo una parte della trama per gli utenti di tutti i giorni.
Il problema delle installazioni "normali" e "out of the box" sono in realtà vulnerabilità nei processi in esecuzione come root. Poiché questi sono affidabili, possono chiedere al kernel di fare quello che vogliono, incluso l'inserimento di moduli del kernel o l'accesso a /dev/kmem .
È importante capire che, per quanto riguarda la CPU, i processi di root vengono eseguiti come processi non privilegiati per quanto riguarda la CPU. Su x86 chiamiamo questo anello 3; sui processori ARM le modalità CPU sono User, FIQ, IRQ,
Supervisore, Abort e Undef, dove User è il livello non privilegiato utilizzato per i processi (tutte le altre modalità sono infatti privilegiate). L'esecuzione dei processi in modalità User non può modificare direttamente altri processi o il kernel; devono prima chiedere al kernel. Tuttavia, dato che sono affidabili, il kernel non "dice di no". Quindi per una configurazione ordinaria, è sufficiente compromettere un processo eseguito come root.
Ora, nel tuo setup le cose sono un po 'diverse - hai disabilitato il caricamento del modulo e l'accesso a /dev/kmem . Per fare un danno serio, devi far eseguire il tuo rootkit in modalità supervisore (suoneria 0 / qualsiasi modalità che non sia User ) o essere in grado di manipolare /dev/kmem . Poiché non è possibile modificare le voci di avvio, questo lascia il livello hardware come il principale vettore di minacce (o ksplice.) Lo menzioni su SO: è sicuramente un rischio perché permetti di applicare patch a un kernel in esecuzione con codice! kexec è un altro potenziale problema perché si sostituisce il kernel in posizione).
Quindi in teoria, quello che hai è molto più sicuro.
Does it mean that the rest of vulnerabilities in that table (e.g., DoS, memory corruption, overflow) cannot be exploited for executing a kernel-level rootkit?
Bene, per occuparci prima dell'ultimo bit - non è necessario essere in grado di sfruttare una vulnerabilità su un sistema "normale" perché si può semplicemente inserire un modulo del kernel. Tuttavia, nel tuo caso questa è praticamente la tua unica strada; dovresti trovare un bug da qualche parte nel sistema che ti permette di caricare il codice o altrimenti può essere sfruttato per controllare il kernel.
Ora, sulla tua osservazione di zero bug - come dici tu, ci sono zero bug conosciuti in quel periodo di tempo. Ciò non significa che non ci siano bug. Inoltre, dovremmo dare un'occhiata a:
- È il kernel della tua distribuzione? Ha patch non presenti nel kernel di vanilla? Queste patch aggiungono anche dei rischi.
- Il tuo kernel richiede un codice aggiuntivo di terze parti (driver di schede grafiche, driver di virtualizzazione)? Se è così, anche questi aumentano il rischio.
Ora, su questi CVE - sì, quando dicono di no "esecuzione di codice" è ciò che significa. Le vulnerabilità presenti possono danneggiare la memoria ed eseguire il DoS ma non possono effettivamente eseguire codice dannoso. Dai un'occhiata a una delle vulnerabilità di esecuzione del codice :
...allow remote attackers to cause a denial of service (panic) or possibly execute arbitrary code...
Quindi sì, così com'è non ci sono vulnerabilità note per l'esecuzione del codice nel kernel al momento della scrittura di Update alla luce di questa risposta Sto attraversando quel bit attraverso - non è chiaro dal sito quale voce rappresenta il kernel vanilla e che rappresentano i kernel forniti dal fornitore, o in effetti qual è la differenza. Lasciatemelo dire che con in qualsiasi definizione del kernel che era c'erano zero vulnerabilità, che è quello che stavo cercando di ottenere prima con parlare di patch fornite da fornitori / codice di terze parti.