Detectaron una vulnerabilidad en ksmbd en el Kernel de Linux
Hace poco se dio a conocer información de que se descubrió una vulnerabilidad del kernel de Linux con una puntuación CVSS de 10 en el servidor SMB, lo que brinda a un usuario no autenticado la capacidad de ejecutar código de forma remota.
El fallo encontrado permite a los atacantes remotos ejecutar código arbitrario en las instalaciones afectadas. No se requiere autenticación para explotar esta vulnerabilidad, pero solo los sistemas con ksmbd habilitado son vulnerables.
La falla específica existe en el procesamiento de los comandos SMB2_TREE_DISCONNECT. El problema resulta de no validar que un objeto existe antes de realizar operaciones en ese objeto. Un atacante puede aprovechar esta vulnerabilidad para ejecutar código en el contexto del kernel.
DETALLES DE LA VULNERABILIDAD
Esta vulnerabilidad permite a los atacantes remotos ejecutar código arbitrario en las instalaciones afectadas del Kernel de Linux. No se requiere autenticación para explotar esta vulnerabilidad, pero solo los sistemas con ksmbd habilitado son vulnerables.La falla específica existe dentro del procesamiento de los comandos SMB2_TREE_DISCONNECT. El problema se debe a la falta de validación de la existencia de un objeto antes de realizar operaciones en el objeto. Un atacante puede aprovechar esta vulnerabilidad para ejecutar código en el contexto del kernel.
Se menciona que dependiendo del tipo de solicitud SMB, cada subproceso nuevo puede decidir pasar comandos al espacio de usuario (ksmbd.mountd); actualmente, los comandos DCE/RPC están identificados para ser manejados por el espacio de usuario. Para hacer un mejor uso del kernel de Linux, se decidió tratar los comandos como elementos de trabajo y ejecutarlos en los controladores de los subprocesos ksmbd -io kworker.
Esto permite multiplexar a los administradores porque el kernel se encarga de iniciar subprocesos de trabajo adicionales si la carga aumenta y viceversa, si la carga disminuye, destruye los subprocesos de trabajo adicionales.
Cuando se inicia el demonio del servidor, inicia un subproceso de bifurcación (ksmbd/nombre de interfaz) en el momento del arranque y abre un puerto dedicado 445 para escuchar las solicitudes de SMB. Cada vez que nuevos clientes hacen una solicitud, el subproceso forker acepta la conexión del cliente y crea un nuevo subproceso para un canal de comunicación dedicado entre el cliente y el servidor. Esto permite que las solicitudes SMB (comandos) de los clientes se procesen en paralelo y permite que nuevos clientes establezcan nuevas conexiones.
ksmbd levantó banderas rojas entre algunos usuarios que discutieron su fusión el año pasado. SerNet, una empresa informática alemana que ofrece su propia versión de Samba, dijo en una publicación de blog que ksmbd era increíble, pero parecía algo inmaduro. Además, el equipo Samba+ de SerNet declaró en una publicación de blog que el valor de agregar un servidor SMB al espacio del kernel puede no valer el riesgo de «exprimir la última parte del rendimiento del material disponible».
Afortunadamente, si no está ejecutando el módulo ksmbd «experimental» de Samsung, como lo describió el investigador de seguridad Shir Tamari en Twitter, y ha conservado Samba, está perfectamente seguro. “ksmbd es nuevo; la mayoría de los usuarios todavía usan Samba y no se ven afectados. Básicamente, si no está ejecutando servidores SMB con ksmbd, disfrute su fin de semana”, tuiteó Tamari.
De acuerdo con Zero-Day Initiative, que reveló la vulnerabilidad ksmbd, la falla use-after-free existe en el procesamiento de los comandos SMB2_TREE_DISCONNECT. Según ZDI, el problema se debe a que ksmbd no valida la existencia de los objetos antes de realizar operaciones en ellos.
Para aquellos que usan ksmbd, existe una solución alternativa además de cambiar a Samba: actualizar a la versión 5.15.61 del kernel de Linux, lanzada en agosto, o posterior. Esta actualización del kernel también soluciona algunos otros problemas en ksmbd: una lectura fuera de los límites para SMB2_TREE_CONNECT, que según la nota del parche podría permitir que las solicitudes no válidas no envíen mensajes, y una fuga de memoria en smb2_handle_negotiate que provoca una liberación incorrecta de la memoria.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.