Esta semana, los principales agregadores de noticias de tecnología empezaron a portar un link a copy.fail, una web donde se alerta de una nueva vulnerabilidad encontrada en el núcleo Linux que afecta a todas las distribuciones Linux lanzadas desde 2017. El nombre real de la vulnerabilidad es CVE-2026-31431, pero fiel a las costumbres modernas, las vulnerabilidades más importantes comercialmente suelen tener algún tipo de nombre, logo y marketing detrás.
En el caso de Copy Fail, las primeras reacciones fueron muy variadas. Por un lado, la web creada alrededor de esta vulnerabilidad es puro marketing de la herramienta de seguridad que la ha encontrado. Sin embargo, la vulnerabilidad es auténtica, y a medida que han ido pasando los días, la cosa se ha ido poniendo cada vez más seria.
En este artículo:
¿Copy qué?
Es complicado leer la vulnerabilidad porque está escrito por una IA y, por lo tanto, tiene ese tono al escribir que, si odias una vez, va a hacer imposible usar internet ahora mismo. De hecho, la primera versión de la página tenía alucinaciones típicas de IA gravísimas, como menciones a Red Hat 14, una versión que RHEL que no existe todavía (apenas vamos por la 10).
Pero sin embargo, la vulnerabilidad es auténtica. Se aprovecha de un bug presente en el código de Linux desde 2017, cuando se modificó un módulo de criptografía de tal manera que quedó por ahí código abandonado que afecta a la caché de páginas, un componente que usa el sistema para reducir y unificar los accesos a disco a la hora de leer o escribir archivos.
Si envías los comandos correctos al núcleo mientras un ejecutable de interés, como su, está en la caché de páginas, puedes sobrescribir parte del código del propio programa de tal manera que si se produce inmediatamente un acceso a ese archivo (por ejemplo, para ejecutarlo) hará que lo que Linux cargue y ejecute sea la copia corrupta en caché.
En la misma web se puede obtener un exploit que permite comprobar si tu sistema es vulnerable (algo que, de todos modos, no deberías ejecutar así como así, aunque sea para probar). Si se invoca, y la versión del núcleo todavía es vulnerable, se obtiene inmediatamente una shell root.
Es un poco complicado de ver en el vídeo que tiene la web porque de por sí el vídeo tiene mal escrito el comando, pero en el siguiente pantallazo se puede ver con precisión que ninguno de los comandos invocados es sudo, y no se pide la contraseña en ningún momento, pero sin embargo se obtiene una shell root, como verifica la llamada a id.
Un bug inicialmente infravalorado
Bendito sea Internet Archive y su función de guardar copias viejas de las webs. Inicialmente, Ubuntu clasificó la vulnerabilidad como de prioridad media. Sin embargo, para el día 30 la vulnerabilidad ya estaba clasificada como de prioridad alta.
Esta vulnerabilidad requiere tener acceso a la shell en primer lugar para poder enviar los comandos. Se trata de una escalada local de privilegios, no de una ejecución de código remota. Aunque es buena idea actualizar tan pronto como sea posible para prevenirse, por el mero hecho de tener expuesto un servidor web a internet no se va a producir un hackeo. Del mismo modo, en tu ordenador personal es problemático que un proceso malintencionado pueda obtener una shell root, pero esto tampoco es nuevo.
Sin embargo, en sistemas multiusuario donde varias personas puedan utilizar un mismo ordenador y enviar comandos, esto sí puede ser un problema para tomar el control de la máquina compartida.
Y aunque no lo parezca, quien cubre esta definición hoy día son todos los sistemas y servicios que permiten ejecutar código en la nube. Por ejemplo, GitHub Actions, GitLab Actions y otros sistemas de CI/CD, donde por su propia naturaleza es imposible predecir el tipo de programa que un runner está ejecutando. Basta con que una de las dependencias porte la vulnerabilidad para que se pueda abrir una shell global desde la que tomar el control del runner, comprometer software o alguna cosa peor.
Un bug muy mal comunicado
Las distribuciones se han puesto manos a la obra en los últimos días para intentar parchear esta vulnerabilidad tan pronto como sea posible. En el caso de Ubuntu, todas las versiones anteriores a Ubuntu 26.04 deberían actualizar. Dado que la corrección entró a Linux mainline en marzo, lo hizo a tiempo para la salida estable de Linux 7.0, y por lo tanto Ubuntu 26.04 está afectado. Sin embargo, en su blog confirman que las versiones anteriores, incluyendo los usuarios del soporte extendido que aún usen Ubuntu 14.04 y Ubuntu 16.04 son vulnerables.
En Debian, el parche está incluido dentro de la Security Announce DSA-6238-1. Ya hay una corrección disponible para Trixie a través del canal de actualizaciones de seguridad. Sin embargo, en el momento de escribir esto todavía no la hay para versiones anteriores de Debian aún en modo LTS, como Debian Bookworm o Debian Bullseye.
La razón probablemente se encuentre en este mensaje de la lista de correo de seguridad oss-security, publicado el día 29 de abril:
Esta es una de las peores vulnerabilidades para volverse root en el kernel que se hayan visto recientemente. Veo que el 11 de abril salieron Linux 6.19.12 y Linux 6.18.22 con la corrección aplicada.
Sin embargo, Linux LTS 6.12, 6.6, 6.1, 5.15 y 5.10 todavía no han recibido la corrección y no veo nada pendiente de ser metido todavía mientras escribo esto. Sospecho que es porque traerse la corrección a estos núcleos no es tan sencillo.
A este post responde un desarrollador de Gentoo que indica que para corregir la versión de Linux que ofrecen en sus repositorios, van a apañar la situación desactivando directamente en el paquete Linux todo el sistema responsable de este bug antes que corregirlo. También se pregunta si es correcto comunicar de esta manera una vulnerabilidad de seguridad sin informar antes a los responsable de las distribuciones GNU/Linux afectadas.
Es verdad que pedir esto es imposible. Pretender notificar a todas las distribuciones GNU/Linux es una tarea titánica porque hay demasiadas. Pero sin embargo, es verdad que el exploit y toda esta información se ha dado antes de que salgan versiones LTS del núcleo que corrigen el error.
En el momento de escribir esto, Linux 6.12.85, Linux 6.6.137, Linux 6.1.170, Linux 5.15.204 y Linux 5.10.254 ya han sido publicadas, y todas portan la corrección aplicada en sus changelogs. Lo hicieron ayer, 30 de abril. Ahora es trabajo de las distribuciones aplicar estos parches dentro de sus versiones LTS, sabiendo que ya se trata de una corrección completa y unificada, no de una ñapa para tapar temporalmente el error.
Sin embargo, es verdad que, históricamente, investigadores de seguridad y distribuidores de software tenían un pacto por el cual, si se admitía a tiempo y se trataba la vulnerabilidad de forma privada, se esperaría a tener una corrección disponible antes de hacer el public disclose, es decir, de comunicarle al mundo el error. De este modo, daría tiempo a los usuarios afectados a actualizar sus sistemas antes que los hackers puedan lanzar aleatoriamente los exploits para intentar atacar sistemas.
Los responsables de proyectos de software libre y código abierto cada vez tienen que enfrentarse a más burocracias. A las contribuciones slop, generadas por inteligencia artificial y sin muchas ventajas más que hacer perder tiempo, se le vienen sumando desde hace tiempo requisitos cada vez más draconianos por parte de una industria tecnológica multimillonaria que, al abrazar el código abierto, ahora quiere externalizar las correcciones de código y ponerse exquisita con su forma de pedir las cosas.
Que ahora una inteligencia artificial super poderosa sea capaz de encontrar de un golpe 200 vulnerabilidades en un navegador web es bueno, porque son 200 oportunidades para corregir problemas. Pero también es frágil, empieza a tirar de las costuras de estos proyectos y a futuro es complicado predecir las consecuencias que puede tener esta acción.
