¡Parchea inmediatamente – Descubren una grave vulnerabilidad en el kernel de Linux!

Justo lo que todo administrador de sistemas Linux no quiere durante las vacaciones: una grave vulnerabilidad de seguridad del kernel de Linux. Zero Day Initiative (ZDI), una firma de investigación de seguridad enfocada en días cero, anunció un nuevo error de seguridad del kernel de Linux. Esta grave vulnerabilidad permite a los usuarios remotos autenticados divulgar información confidencial y ejecutar código en versiones vulnerables del kernel de Linux.

¿Qué tan grave es? Originalmente, el ZDI la calificó con un 10 perfecto en la escala de 0 a 10 del Sistema de Puntuación de Vulnerabilidad Común (CVSS) . Ahora,  la vulnerabilidad ha disminuido su puntuación a “solo” un 9.6. Eso todavía cuenta como un “¡Corrígela! ¡Corrígela ahora!” error en el servidor Linux de cualquier persona.

El problema radica en el servidor de bloque de mensajes del servidor (SMB) en el kernel de Linux 5.15, ksmbd. La vulnerabilidad 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.

Ksmbd

Este nuevo programa, que se introdujo en el kernel en 2021, fue desarrollado por Samsung. Su objetivo era ofrecer un rendimiento rápido de servicio de archivos SMB3. SMB se usa en Windows y Linux a través de Samba como un protocolo de servidor de archivos vital. Ksmbd no pretende reemplazar a Samba sino complementarlo. Los desarrolladores de Samba y ksmbd están trabajando para que los programas funcionen en conjunto. 

Dicho esto, Jeremy Allison, cocreador de Samba, señala: “ksmbd no comparte código con Samba de producción. Es completamente desde cero. Por lo tanto, esta situación actual no tiene nada que ver con el servidor de archivos Samba que puedes estar ejecutando en tus sistemas”. 

Cualquier distribución que use el kernel de Linux 5.15 o superior es potencialmente vulnerable. Esto incluye Ubuntu 22.04 y sus derivados; DeepinLinux 20.3; y Slackware 15. Para propósitos de servidor, Ubuntu es el más preocupante. Otras distribuciones empresariales, como la familia Red Hat Enterprise Linux (RHEL), no utilizan el kernel 5.15.  ¿No estás seguro? Solo debes ejecutar:

$ uname -r 

Para ver qué versión del kernel estás ejecutando.

Luego, si estás ejecutando el kernel vulnerable, para ver si el módulo vulnerable está presente y activo, ejecuta:

$ modinfo ksmb

Lo que quieres averiguar es que no esté presente el módulo. Si está cargado, debes actualizar al kernel de Linux 5.15.61. Desafortunadamente, muchas distribuciones aún no se han movido a esta versión del kernel. 

Vulnerabilidad sin CVE

Algunas personas se estarán preguntado si esto es tan importante, entonces ¿por qué no se le ha dado un número de vulnerabilidades y exposiciones comunes (CVE)? Greg Kroah-Hartmann, el mantenedor del kernel de Linux de la rama estable, explicó: 

“Los desarrolladores del kernel no trabajan con CVE en absoluto, ya que no son tan relevantes en su mayor parte para los problemas del kernel”. Cierto, “Algunas empresas de Linux aún insisten en asignar CVE, pero eso es principalmente para ayudar a habilitar sus procesos de ingeniería internos”.

A otros les preocupa que tal problema pueda existir en un programa del kernel en primer lugar. Como dijo una persona en Ycombinator , esto “parece  una superficie de ataque (externa) bastante significativa para agregar al kernel”. Él no está equivocado. Las implementaciones de SMB de Windows tienen un historial de seguridad largo y feo. En 2020, por ejemplo, SMBGhost, también conocido como CoronaBlue, abrió las PCs con Windows 10 a los ataques de seguridad de SMB. 

No son solo los usuarios los que se han preocupado por la seguridad de ksmbd. Antes de este episodio, Kees Cook, un desarrollador senior de seguridad del kernel de Linux, escribió: 

“Algunas de estas vulnerabilidades son propiedades de seguridad del sistema de archivos bastante fundamentales que no se estaban probando, además del caso molesto de tener desbordamientos de búfer en un servidor de sistema de archivos en el kernel” 

Cook concluyó: “Estoy preocupado por la calidad del código aquí, y creo que algo debe cambiar en los procesos de revisión y prueba”.

Si bien se hicieron correcciones,este último episodio muestra que el código necesita más limpieza y seguridad antes de que los usuarios estén listos para confiar en él en producción. Sería prudente parchear el kernel por ahora y dejar de usarlo también; lo ideal sería usar Samba, por el momento.