- LiMux, el proyecto para llevar Linux a más de 14.000 ordenadores que acabó volviendo a Windows con el rabo entre las piernas
- Estas 5 distribuciones Linux meten la IA hasta la cocina: agentes, modelos locales y búsquedas inteligentes
Seis avisos de vulnerabilidades críticas del kernel de Linux se han publicado esta semana por error en una lista de correo abierta, donde cualquiera puede leer los detalles del ataque, mientras no existe todavía parche oficial en la rama principal del sistema. Te contamos qué ha pasado y qué puedes hacer si usas Linux.
El origen del incidente está en Zero Day Initiative, la división de Trend Micro que rastrea fallos de seguridad en los principales programas del mundo. Sus analistas remitieron los seis avisos a la lista pública en la que se discute el desarrollo del kernel, cuando lo propio del caso era mandarlos al canal privado reservado para la seguridad. Greg Kroah-Hartman, el número dos del proyecto, respondió a cada informe uno por uno para preguntar por qué habían acabado a la vista de todos, en un informe destapado por Phoronix.
El caso llega al final de una semana especialmente intensa en la materia. Ayer mismo te contamos cómo el fallo de PHP amenazaba a millones de webs. Te contamos todo lo que sabemos hasta ahora.
Qué ha ocurrido
La seguridad del kernel funciona con una regla sencilla. Cuando un investigador encuentra un fallo, lo manda a una lista privada, los mantenedores preparan el parche, lo prueban y lo reparten con las versiones estables de las distribuciones. Solo al final, con la corrección ya en la calle, se publican los detalles.
Esa regla existe por un motivo que es clave para evitar problemas mayores. Los detalles del ataque son parte esencial del trabajo de cualquier hacker, y la ventana entre el aviso y el parche es el tiempo en el que los administradores de sistemas conservan la ventaja. Con los informes en una lista pública, la ventaja cambia de bando y son los ciberdelincuentes los que tienen todo el tiempo que necesitan para explotar la brecha de seguridad.
Es importante tener en cuenta que el error no fue puntual. Uno de los seis avisos, el del fallo de menor gravedad, ya se había publicado por error en la misma lista un día antes que los otros cinco. Los parches de varios de los fallos estaban en fase de pruebas o en ramas de desarrollo, pero ninguno había llegado a la rama principal en el momento de la filtración. Lo publicado, además, ya no se puede retirar.
Los dos fallos más importantes
De los seis avisos, dos destacan sobre el resto. Son los que alcanzan una puntuación CVSS de 9 sobre 10, y comparten el perfil más peligroso, porque permiten ejecutar comandos en la máquina afectada sin necesidad de tener ningún acceso previo a ella.
El primero, identificado como ZDI-CAN-33549, afecta a SMB Direct, el protocolo con el que los equipos comparten archivos y recursos. El segundo, ZDI-CAN-33774, es una condición de carrera en KSMBD, el servidor de archivos que el propio kernel lleva integrado.
En ambos casos, el escenario de riesgo es el mismo. Un servidor con los servicios de archivos expuestos a internet queda directamente expuesto mientras no llegue el parche.
Otros cuatro fallos más
Los otros cuatro avisos son de un perfil distinto. Tres de ellos permiten la escalada de privilegios local. Es decir, que un atacante con un acceso limitado a la máquina, por ejemplo una cuenta de bajo nivel o un programa comprometido, puede convertirse en administrador. Uno de los tres está en el código de red, otro en el controlador gráfico de VMware, habitual en entornos virtualizados, y el tercero es un desbordamiento de búfer en consultas TCP.
El último de los seis (ZDI-CAN-32005) tiene un alcance menor. Provoca la divulgación de información por un recurso sin inicializar en el subsistema de almacenamiento por red, un fallo que expone datos en lugar de entregar el control de la máquina.
Qué puedes hacer para evitar riesgos innecesarios
La recomendación general es la de siempre. Mantén el sistema actualizado y vigila los canales oficiales de tu distribución. En el caso de los servidores, la prudencia pide dar un paso adicional. Si compartes archivos por SMB o KSMBD, o usas los gráficos de VMware en máquinas virtuales, conviene cerrar esos servicios al exterior o restringirlos a la red interna hasta que se confirme la publicación de las correcciones.
En un contexto como el actual, en el que la filtración aumenta el riesgo de forma exponencial, te recomendamos que extremes las precauciones hasta que lleguen los parches.