kernel: deshabilitar / dev / kmem y / dev / mem

Entiendo eso /dev/kmemy /dev/memproporciono acceso a la memoria (es decir, RAM sin formato) del sistema. También soy consciente de que /dev/kmempuede deshabilitarse completamente en el núcleo y que el acceso puede restringirse /dev/mem.

Me parece que tener acceso en bruto a la memoria puede ser útil para desarrolladores y hackers, pero ¿por qué debería necesitar acceso a la memoria /dev/mem? AFAIK no se puede deshabilitar en el núcleo (a diferencia /dev/kmem). Tener acceso a memoria en bruto que puede ser potencialmente abusado / explotado me parece que solo estoy buscando problemas.

¿Hay algún uso práctico para ello? ¿Algún programa de usuario requiere que funcione correctamente?

Hay una plataforma de diapositivas de Scale 7x 2009 titulada: Socavando el kernel de Linux: inyección de código malicioso a través de / dev / mem que contenía estas 2 viñetas.

¿Quién necesita esto?

• Servidor X (memoria de video y registros de control)
• DOSEmu

De todo lo que he encontrado en la búsqueda hasta ahora, parece que estas 2 viñetas son las favoritas para usos legítimos.

Referencias

• Anthony Lineberry en / dev / mem Rootkits - LJ 8/2009 por Mick Bauer
• ¿Quién necesita / dev / kmem?

Vale la pena señalar que incluso si se deshabilitó /dev/memy /dev/kmemesa memoria todavía se puede volcar; mira man procpara revelar /proc/kcore; Es la memoria física del sistema. Un kit de herramientas forenses realmente bueno rekall tiene una herramienta que ya hace esto ; vuelca la memoria (y/boot archivos) para que puedan ser analizados.

De hecho, Ubuntu deshabilita por defecto/dev/kmem :

No hay un uso moderno de /dev/kmemmás allá de los atacantes que lo usan para cargar rootkits de kernel. CONFIG_DEVKMEMse establece en "n". Si bien el /dev/kmemnodo del dispositivo todavía existe en Ubuntu 8.04 LTS a través de Ubuntu 9.04, en realidad no está conectado a nada en el núcleo.

Ubuntu no se desactiva /dev/memporque las aplicaciones lo necesitan .

Algunas aplicaciones (Xorg) necesitan acceso directo a la memoria física desde el espacio del usuario. El archivo especial /dev/memexiste para proporcionar este acceso. En el pasado, era posible ver y cambiar la memoria del núcleo de este archivo si un atacante tenía acceso de root. La CONFIG_STRICT_DEVMEMopción del kernel se introdujo para bloquear el acceso a la memoria que no es del dispositivo (originalmente llamado CONFIG_NONPROMISC_DEVMEM).

Cómo deshabilitar /proc/kcore ?

No actives CONFIG_PROC_KCORE al construir el núcleo.

¿Cómo deshabilitas? /dev/mem ?

Bueno, mirar man memnos da algunos detalles sobre cómo se creó:

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

Deberías poder simplemente rm -rf /dev/mem; puede deshabilitar durante la fase de compilación del núcleo al no habilitar CONFIG_STRICT_DEVMEM.

¿Cómo deshabilitar/dev/kmem ?

Asegúrese de que CONFIG_DEVKMEMno esté habilitado en la compilación del núcleo.

¿Cómo prevenir los ataques de arranque en frío?

¿Qué pasa si yo era capaz de desactivar /proc/kcore, /dev/mem, /dev/kmemy luego utiliza una partición de intercambio cifrada o no usó de intercambio en absoluto? Bueno, tu memoria podría congelarse y accederse de esa manera. ¿Cómo se previene este ataque? Cifras tu RAM; ¿Cómo encriptas tu RAM? No puedes Ver TRESOR para más detalles .

Como sabe, /dev/memproporciona acceso a la memoria física de un sistema en ejecución. /dev/kmemproporciona acceso a la memoria virtual del kernel. Ambos dispositivos de caracteres se pueden deshabilitar de forma persistente a través de las opciones de configuración del núcleo (el código es la fuente de información más autorizada, por lo que se utiliza como referencia). Desarmar las dos primeras opciones a continuación deshabilitará los dispositivos correspondientes.

• CONFIG_DEVKMEM: determina si /dev/kmemse crea en el arranque
• CONFIG_DEVMEM: determina si /dev/memse crea en el arranque
• CONFIG_STRICT_DEVMEM: si /dev/memexiste, determina si el acceso está restringido

Dependiendo de su distribución, su configuración actual del núcleo se puede ver usando algo como zless /proc/config.gzoless /boot/config-$(uname -r) .

Creo que la intención inicial de /dev/memera apoyar la interacción con periféricos mapeados en memoria . Las implicaciones negativas de seguridad obvias de tener estos dispositivos virtuales disponibles (por ejemplo, un atacante que puede parchear sobre la marcha la memoria de otro proceso o incluso el núcleo) se conocen desde hace al menos una década. La restricción del acceso a /dev/memha sido admitida en el núcleo principal desde principios de 2008 , /dev/kmemtambién ha sido opcional desde entonces. .

Hace una década parece que Xdependía /dev/mem, no creo que esto sea cierto. Para probar las afirmaciones sobre la Xnecesidad /dev/mem, eliminé el dispositivo virtual de mi computadora portátil ayer y ha estado funcionando aparentemente perfecto desde entonces. En 2017 parece que no hay un uso práctico para estos dispositivos fuera de la investigación y el desarrollo.

Desde una perspectiva de seguridad, es una buena idea eliminar estos dispositivos. Todavía vale la pena señalar que un atacante remoto , con privilegios elevados, puede leer la memoria fuera de su espacio de direcciones. Se puede acceder a la memoria de otras aplicaciones de espacio de usuario mediante /proc/<pid>/mem. Se puede acceder a la memoria del núcleo mediante /proc/kcore.

No incluí /dev/memen mi sistema desde el principio. Utilizo Gentoo Linux, por lo que esto puede no ser una sorpresa, ya que con esta distribución de Linux prácticamente construyes todos los paquetes tú mismo, incluido el kernel de Linux.

Nunca noté ningún problema debido a la falta de /dev/mem, incluso cuando uso X.org X11. Justo hoy noté que una aparición del paquete x11-drivers/xf86-video-vesaimprime un mensaje que indica que requiere /dev/mem, como este:

* This driver requires /dev/mem support in your kernel
*   Device Drivers --->
*     Character devices  --->
*       [*] /dev/mem virtual device support

Como no instalé el controlador VESA para el XServer intencionalmente, o incluso si solo fuera una alternativa, en realidad nunca tuve que usarlo y, por lo tanto, no lo noté, hasta ahora.

Pero esto prueba el punto de que a) X11 ya no necesita /dev/mem, y b) que algunos controladores de video X11 aún pueden hacerlo de todos modos.

Los controladores de video más nuevos para hardware específico probablemente funcionarán sin él. Al igual que el X.org-X11 moderno (en Gentoo x11-base/xorg-server) , ya no tiene que ser suid root , así es como se ve el progreso ...