Soporte técnico
Documentación
Inicio de sesión
Póngase en contacto con nosotros
La nueva funcionalidad del núcleo de Linux equivale a una nueva superficie de ataque
Joao Correia
29 de diciembre de 2022 - Evangelista técnico
El Kernel Linux ha crecido en alcance y funcionalidad a lo largo de los años. Nuevos programadores, nuevos controladores, nuevos sistemas de archivos, nuevos protocolos de comunicación, nuevos agujeros de seguridad... oh, espera. Este último no es como los demás. En realidad, los nuevos agujeros de seguridad suelen ser el resultado de nuevas funcionalidades añadidas. Claro, no todas las nuevas funcionalidades añaden nuevas vulnerabilidades de seguridad - pero las que lo hacen hablan de una base de código masiva que es propensa a interacciones inesperadas, oscuras y ofuscadas que dan lugar a situaciones peligrosas.
¿Cómo se añade funcionalidad?
Todos y cada uno de los subsistemas del núcleo han sido, en algún momento, lo suficientemente útiles como para que alguien los enviara para su inclusión en la base de código principal del núcleo. La mayoría de estos subsistemas, si no todos, podrían implementarse en el espacio de usuario en lugar de directamente en el núcleo, pero el objetivo final de quien envía este tipo de código es obtener todo el rendimiento posible. Estar directamente dentro del espacio de ejecución del Kernel significa que hay menos cambios de contexto, acceso directo a regiones de memoria que de otro modo estarían fuera de alcance, y en general llamadas más fáciles y rápidas a otras funcionalidades del núcleo y acceso al hardware.
A lo largo de los años, esto ha llevado a una proliferación de, por ejemplo, sistemas de archivos (ahora hay docenas de diferentes sistemas de archivos soportados directamente desde el Kernel), NTFS, exFAT, XFS, y muchos, muchos, otros - y todos ellos tienen una razón de peso para ser parte del Kernel. Lo mismo puede decirse de los módulos de filtrado de paquetes, los protocolos de red y todo lo demás. Hay muchos otros que se están sometiendo a revisiones y reescrituras para su futura inclusión (¿alguien quiere ZFS?). ¿Cuántos sistemas de archivos se necesitan realmente en un sistema determinado?
Lo mismo podría decirse de la depuración, ya que existen múltiples funcionalidades para proporcionar depuración dentro del Kernel. A veces incluso compiten entre sí y no pueden habilitarse al mismo tiempo.
Es parecido a esto:
¿Cuál es el truco?
Cuando se creó el núcleo Linux, Internet era una mota de polvo comparado con lo que es hoy. El número de sistemas conectados en red e incluso el total de redes en todo el mundo podía contarse y enumerarse con relativa facilidad. Probablemente conocías por su nombre a los operadores de los sistemas a los que te conectabas habitualmente. La ciberseguridad no existía.
Así pues, añadir nuevas funciones al núcleo amplió el alcance del proyecto y de una gran pieza de software, además de permitir una gran expansión de la base de usuarios, que se convirtió en el núcleo de entusiastas de Linux que lideró el proyecto cuando éste alcanzó un tamaño suficientemente significativo.
No había muchas razones para no incluir algo nuevo e interesante para alguien. Lo contrario era cierto: más funciones significaba más usuarios interesados.
Las cosas han cambiado. Bastante, de hecho.
Deje su equipaje en la puerta
Resulta que añadir muchas piezas complejas de código a algo que crece por acumulación a veces introduce resultados inesperados.
Tomemos como ejemplo el subsistema Berkley Packet Filter (BPF). Inicialmente concebido y propuesto como una forma de añadir nuevas implementaciones de cortafuegos a medida, permite a los usuarios añadir lo que equivale básicamente a cualquier código y ejecutarlo en el contexto de ejecución del Kernel de Linux. También ha sido la fuente de docenas de vulnerabilidades, algunas bastante graves, en los últimos años. Dado su propósito, no es totalmente inesperado.
Otras no son tan claras en cuanto a los riesgos que introducen.
Consideremos otro ejemplo. El año pasado, el subsistema ksmbd fue propuesto y aceptado en el Kernel. Es algo similar a Samba (es decir, permite el uso compartido de archivos SMB directamente, en lugar de depender de un software independiente). En última instancia, debería proporcionar velocidades de transferencia SMB más rápidas al basarse en profundidades de pila de llamadas más cortas (llamando a funciones del Kernel directamente en lugar de a través de la ABI del Kernel, como Samba). Conociendo el historial de vulnerabilidades, gusanos, exploits y otras historias desagradables de SMB, podría haber algún motivo para preocuparse, pero se metió en el Kernel, patrocinado por Samsung. Por supuesto, siendo la ciberseguridad lo que es, hace sólo un par de días se hizo público que existía una vulnerabilidad de riesgo 10 (sobre 10) en ksmbdtal y como existe en el código base del Kernel 5.15 (utilizado por Ubuntu 22.04, por ejemplo).
No nos limitamos a añadir nuevas funciones. Estamos añadiendo todos los errores e interacciones inesperadas entre el código nuevo y el antiguo que, por desgracia, solo son evidentes en los sistemas de producción.
Otro trozo de carbón por Navidad
Así que, al igual que el infame Log4j del año pasado, la temporada de vacaciones es terreno fértil para que broten vulnerabilidades muy peligrosas. Al igual que los administradores de sistemas y los equipos de seguridad lucharon para solucionar Log4j y parchearlo a tiempo, esta nueva vulnerabilidad ksmbd es otra vulnerabilidad de "parchea ahora o serás hackeado". Es explotable remotamente, fácil de activar y da acceso total al sistema. Hasta ahora, aparentemente un usuario tiene que estar autenticado en un recurso compartido para poder activarla - así que hay algunas buenas noticias, pero sigue siendo bastante grave. "Parchear ahora" es un eufemismo.
Además, ¿qué pasa con las nuevas vulnerabilidades que salen cuando los equipos de TI están funcionando con equipos esqueléticos y son más lentos para reaccionar? Oh, espera...
Consideraciones sobre las causas profundas
Esto no es un ataque a subsistemas específicos. Ni siquiera es una crítica al propio Kernel o a su proceso de desarrollo: su innegable éxito es evidente. Pero, y siempre hay un "pero", quizá los nuevos subsistemas deberían permanecer más tiempo en pruebas. O, cuando ya se puede conseguir una funcionalidad similar en el espacio de usuario, quizá no debería aceptarse en absoluto la inclusión del núcleo. Todo el mundo tiene siempre una historia convincente detrás de una petición, y siempre es la "siguiente mejor cosa" desde el pan rebanado. El diablo proverbial está, en este caso, en los detalles (de implementación).
Al igual que el panorama de la seguridad es cada vez más peligroso, quizá sea hora de endurecer los requisitos para aceptar nuevos sistemas. Al fin y al cabo, sólo hay un número limitado de ojos disponibles para vigilar las cosas.
Hay cientos de miles de líneas de código en el Kernel, y no es posible tener en cuenta todas las interacciones extrañamente bellas entre el nuevo código y todas las partes viejas que aún permanecen de los primeros días. ¿Quién puede garantizar que un nuevo sistema de archivos que se está añadiendo no hará saltar un fusible cuando se utilice en un sistema con un programador que apenas se usa? ¿Son las suites de prueba tan buenas como para tenerlo en cuenta? ¿O se trata simplemente de otra sorpresa que espera golpear a los equipos informáticos en las próximas temporadas de vacaciones?
A mí, por mi parte, me gustaría poder disfrutar de mi ponche de huevo en lugar de preocuparme por los hackers en mis sistemas durante la Navidad.
