Sí, el suckit rootkit tal como aparece en Phrack es uno ejemplo, que modifica el kernel de Linux a través de /dev/kmem . Esencialmente, los objetivos siguen siendo los mismos: reemplazar las entradas en la tabla de llamadas del sistema para hacer lo que queremos que hagan. La diferencia aquí es que la modificación se realiza a través de /dev/kmem .
Los parches grsecurity / PaX para el kernel incluyen soporte / configuración para deshabilitar el acceso a /dev/kmem , /dev/mem y /dev/port - vea la entrada aquí .
La diferencia entre /dev/mem y /dev/kmem se explica aquí .
La notable diferencia entre modificar la memoria de esta manera y cargar en un módulo del kernel es la exposición de los símbolos. La mayoría de los rootkits de módulos del kernel se compilan con las funciones static , por lo que estas funciones no se exportan desde el código; sin embargo, hay otras técnicas que podrían traicionar la existencia de un módulo del kernel (la función init debería ser exportable, por ejemplo). Un rootkit que modifica directamente la memoria del kernel no sería visible en un escaneo del espacio de direcciones del kernel excepto en lo que había cambiado (es decir, si sabe dónde debería apuntar la tabla syscall y a qué apunta). es posible que lo detecte, a menos que el autor sea lo suficientemente inteligente como para garantizar que las lecturas adicionales de /dev/kmem proporcionen las direcciones correctas).
En cuanto a si un tipo malo puede modificar directamente la memoria: un proceso de raíz está técnicamente aún en el espacio del usuario; es decir, sigue siendo parte del anillo 3 y no tiene la capacidad de escapar de su memoria virtual. La única memoria que un proceso de anillo 3 puede modificar es su propio espacio de direcciones virtuales, que en lo que respecta a es el aspecto de la memoria . Un proceso de anillo 3 debe cumplir con todas las reglas de la memoria marcada; por ejemplo, si una página está marcada como de solo lectura, no puede ser modificada por un proceso (la CPU se niega e informa al sistema operativo). Sin embargo, un proceso de anillo 0 (modo cpu supervisor) puede modificar cualquier memoria que le guste y puede ir tan lejos como para pedirle a la CPU que ignore el estado de las páginas de memoria (es decir, puede ignorar el hecho de que las páginas son de solo lectura).
Entonces, lo que estoy tratando de entender es que un proceso raíz no tiene acceso implícito a la memoria por ser un proceso raíz; aún así, debe solicitar y obtener dicho acceso a través del kernel. Es solo que el núcleo obedecerá a ciegas. Entonces, una solución es usar los parches PaX, haciendo que el kernel rechace tales solicitudes.