Las vulnerabilidades en el núcleo mismo, si bien son serias, son solo una parte de la historia para los usuarios diarios.
El problema para las instalaciones "normales", "listas para usar" son de hecho vulnerabilidades en procesos que se ejecutan como root. Ya que estos son de confianza, pueden pedirle al kernel que haga lo que quiera, incluida la inserción de módulos del kernel o el acceso a /dev/kmem .
Es importante comprender que, en lo que respecta a la CPU, los procesos raíz se ejecutan como procesos sin privilegios en lo que respecta a la CPU. En x86 llamamos a este anillo 3; en los procesadores ARM, los modos de CPU son Usuario, FIQ, IRQ,
Supervisor, Abort y Undef, donde User es el nivel no privilegiado utilizado para los procesos (todos los demás modos son privilegiados). La ejecución de procesos en modo User no puede modificar otros procesos o el kernel directamente; Deben preguntar primero al núcleo. Sin embargo, como son de confianza, el kernel no "dice no". Por lo tanto, para una configuración normal, es suficiente comprometer un proceso que se ejecuta como root.
Ahora, en su configuración, las cosas son un poco diferentes: ha deshabilitado la carga del módulo y el acceso a /dev/kmem . Para hacer un daño grave, debe hacer que su rootkit se ejecute en modo supervisor (timbre 0 / cualquier modo que no sea User ) o poder manipular /dev/kmem . Ya que tampoco puede modificar las entradas de inicio, esto deja al nivel de hardware como el principal vector de amenaza (o ksplice. Usted menciona que en SO; definitivamente es un riesgo porque permite parchar un kernel en ejecución con código. kexec es otra problema potencial porque reemplaza el kernel en su lugar).
En teoría, lo que tienes es significativamente más seguro.
¿Significa que el resto de vulnerabilidades en esa tabla (por ejemplo, DoS, corrupción de memoria, desbordamiento) no se pueden explotar para ejecutar un rootkit a nivel de kernel?
Bueno, para lidiar con el último bit primero, no necesita poder explotar una vulnerabilidad en un sistema "normal" porque solo puede insertar un módulo de kernel. Sin embargo, en tu caso esta es prácticamente tu única vía; necesitaría encontrar un error en algún lugar del sistema que le permita cargar código o pueda ser explotado para controlar el kernel.
Ahora, en su observación de cero errores, como dice, hay cero errores conocidos en ese período de tiempo. Eso no significa que no haya errores. Además, debemos advertir esto con:
- ¿Es este el núcleo de su distribución? ¿Tiene parches que no están presentes en el kernel de vainilla? Estos parches también agregan riesgo.
- ¿Su kernel requiere un código adicional de terceros (controladores de tarjetas gráficas, controladores de virtualización)? Si es así, estos también agregan riesgo.
Ahora, sobre esos CVE: sí, cuando dicen que no "ejecución de código" eso es lo que significa. Las vulnerabilidades presentes pueden dañar la memoria y realizar DoS, pero en realidad no pueden ejecutar código malicioso. Eche un vistazo a una de las vulnerabilidades de ejecución de código :
... permite que los atacantes remotos causen una denegación de servicio (pánico) o posiblemente ejecuten código arbitrario ...
Así que sí, tal como está, no hay vulnerabilidades conocidas de ejecución de código en el núcleo en el momento de escribir Actualizar a la luz de esta respuesta Estoy cruzando ese bit: no está claro desde el sitio qué entrada representa el núcleo de vainilla y cuáles representan los núcleos suministrados por el proveedor, cual es la diferencia Permítanme advertir que con en cualquier definición del kernel que fue no hubo vulnerabilidades, que es lo que estaba tratando de lograr antes con la charla de parches suministrados por el proveedor / código de terceros.