Justo lo que todo administrador de sistemas Linux desea justo antes de las vacaciones: Un grave fallo de seguridad en el núcleo de Linux. La Zero Day Initiative (ZDI), una empresa de investigación de seguridad de día cero, ha anunciado un nuevo fallo de seguridad del kernel de Linux. Este agujero permite a usuarios remotos autenticados revelar información sensible y ejecutar código en versiones vulnerables del kernel de Linux.
¿Cuál es su gravedad? En un principio, el ZDI lo calificó con un 10 perfecto en la escala de 0 a 10 del sistema común de puntuación de vulnerabilidades (CVSS). Ahora, el agujero es «sólo» un 9,6. Eso sigue contando como un fallo «¡Páchalo! Patch it now!» en cualquier servidor Linux.
El problema radica en el servidor Linux 5.15 in-kernel Server Message Block (SMB), ksmbd. El fallo específico existe en el 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 él. Un atacante puede aprovechar esta vulnerabilidad para ejecutar código en el contexto del kernel.
Este nuevo programa, que se introdujo en el kernel en 2021, fue desarrollado por Samsung. Su objetivo era ofrecer un rendimiento rápido en el servicio de archivos SMB3. SMB se utiliza en Windows en Linux, a través de Samba como un protocolo de servidor de archivos vital. Ksmbd no pretende sustituir a Samba, sino complementarlo. Los desarrolladores de Samba y ksmbd están trabajando para que los programas funcionen conjuntamente.
Dicho esto, Jeremy Allison, cocreador de Samba, señala: «ksmbd no comparte código con Samba de producción. Es completamente nuevo. Por lo tanto, esta situación actual no tiene nada que ver con el servidor de archivos Samba que pueda estar ejecutando en sus sistemas».
Cualquier distribución que utilice el kernel Linux 5.15 o superior es potencialmente vulnerable. Esto incluye Ubuntu 22.04, y sus descendientes, y Deepin Linux 20.3. A efectos de servidores, Ubuntu es la más preocupante. Otras distribuciones empresariales, como la familia Red Hat Enterprise Linux (RHEL), no utilizan el kernel 5.15. ¿No está seguro? Solo tienes que ejecutar
$ uname -r
To see which kernel version you’re running.
Then, if you’re running the susceptible kernel, to see if the vulnerable module is present and active run:
$ modinfo ksmb
Lo que quieres ver es que no se encontró el módulo. Si está cargado, querrá actualizar al kernel Linux 5.15.61. Muchas distros, desafortunadamente, no se han movido a esta versión del kernel todavía.
Algunas personas se han 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, mantenedor de la rama estable del kernel Linux, ha explicado que «los desarrolladores del kernel no trabajan con los CVE en absoluto, ya que en su mayor parte no son tan relevantes para los problemas del kernel». Cierto es que «algunas empresas de Linux siguen insistiendo en asignar CVE, pero es sobre todo para facilitar sus procesos internos de ingeniería».
A otros les preocupa, en primer lugar, que un problema de este tipo pueda existir en un programa del kernel. Como dijo una persona en Ycombinator, esto «parece una superficie de ataque (externa) bastante significativa para añadir al kernel.» No se equivoca. Las implementaciones SMB de Windows tienen una larga y fea historia de seguridad. En 2020, por ejemplo, SMBGhost, alias CoronaBlue, abrió los PC con Windows 10 a ataques de seguridad SMB.
No solo los forasteros se han preocupado por la seguridad de ksmbd. Antes de este episodio, Kees Cook, desarrollador sénior de seguridad del kernel de Linux, escribió: «Algunos de estos fallos son propiedades de seguridad del sistema de archivos bastante fundacionales que no se estaban comprobando, aparte del inquietante caso de tener desbordamientos de búfer en un servidor del sistema de archivos dentro del kernel». Cook concluyó: «Me preocupa la calidad del código en este caso, y creo que algo tiene que cambiar en los procesos de revisión y comprobación.»
Se hicieron correcciones, pero este último episodio demuestra que el código necesita más limpieza y seguridad antes de que yo, por mi parte, esté listo para confiar en él en producción. Sería prudente parchear el kernel por ahora y dejar de usarlo, también, en favor de Samba por el momento.
