Las vulnerabilidades del kernel de Linux no se notifican con anticipación a las distribuciones

 (openwall.com)
1 puntos por GN⁺ 2 시간 전 | 1 comentarios | Compartir por WhatsApp
  • CopyFail, una vulnerabilidad de escalación local de privilegios en el kernel de Linux, está entre las más graves de las recientes vulnerabilidades del tipo “make-me-root” del kernel
  • El problema fue introducido en el commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 de la versión 4.14 y fue corregido en 6.18.22, 6.19.12 y 7.0
  • Las versiones 6.19.12 y 6.18.22 incluyeron el backport de la corrección el 11 de abril, pero en ese momento la corrección no llegó a las versiones Longterm 6.12, 6.6, 6.1, 5.15 y 5.10
  • La corrección no se aplicó de forma clean apply en kernels antiguos y, en situaciones donde se requiere un despliegue inmediato, puede usarse como mitigación temporal un parche para desactivar el módulo authencesn de IPSec
  • Las vulnerabilidades del kernel de Linux no se notifican con anticipación a las distribuciones a menos que quien las reporte las lleve a la linux-distros ML, y en este caso tampoco hubo heads-up

Alcance del CVE-2026-31431 y estado de la corrección

  • CopyFail es una vulnerabilidad de escalación local de privilegios en el kernel de Linux y está entre las más graves de las recientes vulnerabilidades del tipo “make-me-root” del kernel
  • El problema fue introducido en el commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 de 4.14 y fue corregido respectivamente en 6.18.22, 6.19.12 y 7.0
  • Commit de corrección en 6.18.22
  • Commit de corrección en 6.19.12
  • Commit de corrección en 7.0
  • Las versiones 6.19.12 y 6.18.22 se publicaron el 11 de abril con el backport de la corrección incluido
  • En ese momento, la corrección no había llegado a las versiones Longterm 6.12, 6.6, 6.1, 5.15 y 5.10, y tampoco aparecía en la cola estable upstream
  • Si el problema fue introducido en 2017, es necesario verificar si también afecta a kernels más antiguos

Notificación previa a distribuciones y mitigación temporal

  • Esa corrección no hace clean apply en kernels antiguos
  • Se intentó hacer el backport porque era una situación que requería despliegue inmediato, pero debido a varios cambios de API era difícil avanzar con certeza
  • Como mitigación temporal puede usarse un parche para desactivar el módulo authencesn de IPSec, y aun sin ser especialista en IPSec, parece una “opción menos mala”
  • 0001-crypto-disable-authencesn-module-for-CVE-2026-31431.patch: parche para desactivar el módulo authencesn como respuesta a CVE-2026-31431
  • Las vulnerabilidades del kernel de Linux no se notifican con anticipación a las distribuciones a menos que quien las reporte las lleve a la linux-distros ML
  • En este caso no hubo heads-up a través de la linux-distros ML

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 시간 전
Comentarios en Hacker News

  • Sam James, el autor del artículo enlazado, es desarrollador de Gentoo
    En cualquier caso, esto estuvo cerca de ser un desastre, y fue muy irresponsable publicar el exploit antes de que las distribuciones pudieran desplegar los arreglos
    No hay forma de saber cuántos proveedores de hosting compartido habrán sido comprometidos por esto
    También preocupa que no parezca haber comunicación entre el kernel security team y los maintainers de las distribuciones
    Uno esperaría que los primeros avisaran a los segundos, pero en la práctica parece una estructura donde la responsabilidad recae en quien descubre la vulnerabilidad

    • No veo problema en hacerlo público 30 días después de que el parche haya llegado al destinatario del reporte
      Como referencia, Google Project Zero usa una política similar de “90+30”: https://projectzero.google/vulnerability-disclosure-policy.h...
      El verdadero problema es que no existe un canal de comunicación entre el kernel security team y los maintainers de las distribuciones
      La persona que descubre la vulnerabilidad no debería cargar con la responsabilidad de reportarla por separado a todos los downstream
      El equipo del kernel debió avisar a la lista de responsables de seguridad de las distribuciones sobre la severidad del parche y la fecha de divulgación 30 días después
    • Esta divulgación estuvo más cerca del marketing que de la seguridad
      En la página de divulgación aparecen frases como “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, y “[Try Xint Code]”
      Es una forma de hacer que el producto se vea más atractivo mientras más confusión genere
    • Como usuario y administrador, no estoy de acuerdo con que esto haya sido “muy irresponsable”
      La expresión Responsible Disclosure, igual que “Secure Boot”, está lingüísticamente muy bien diseñada, pero en la práctica parece servir para gestionar la reputación de las organizaciones intermedias —empresas y fundaciones— que están entre mi computadora y yo
      A ellos les interesa más evitar que se diga “RHEL es vulnerable” o “Ubuntu es vulnerable” que saber si mi computadora individual está expuesta
      La vulnerabilidad existe de todos modos, así que prefiero tener la oportunidad de conocer el riesgo y mitigarlo en vez de solo esperar a que lo arreglen en silencio
      Es decir, creo que la divulgación inmediata es la única opción que no es irresponsable
    • Independientemente de la postura sobre el proceso de divulgación, si un proveedor de hosting fue comprometido por esto, su diseño ya estaba condenado a perder
      No es aceptable ejecutar cargas de trabajo de tenants que no confían entre sí bajo un único kernel compartido
      Los LPE del kernel no son raros, y este en particular solo era especialmente simple y portable, mientras que la capacidad ofensiva básica ya es casi un commodity del CNE
    • El Linux kernel no es adecuado para usarse como frontera de seguridad
      Si haces shared hosting y no quieres que te comprometan, deberías usar otros mecanismos como gVisor o VMs con Firecracker
      Android es más o menos el único sistema importante que sí lo usa como frontera de seguridad, y lo mitiga con aprobación del usuario para instalar APKs, políticas estrictas de SELinux y seccomp, y el hardening de GrapheneOS
      En este caso la mitigación sí funcionó: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

  • No entiendo por qué se dice algo como “en el caso de una vulnerabilidad del Linux kernel, las distribuciones no reciben aviso previo a menos que el reporter la lleve directamente a la lista linux-distros ML”
    Que el reporter tenga que coordinarse directamente con las distribuciones presupone un nivel alto de conocimiento del proyecto Linux
    Quien reporta una vulnerabilidad no debería ser responsable de trabajar directamente con todos los consumidores downstream del Linux kernel
    Bajo esa lógica, también habría que contactar individualmente a todos los fabricantes que usan Linux en sus equipos
    Considero que el reportero ya hizo suficiente con divulgar responsablemente a Linux y esperar hasta que el parche estuviera integrado
    Dentro del proyecto Linux debería haber personas con autoridad y responsabilidad sobre las vulnerabilidades de seguridad, y ellas deberían encargarse de avisar a las distribuciones downstream

    • Más aún porque se les pide explícitamente a los reporters que no avisen primero a los equipos de las distribuciones
      https://docs.kernel.org/process/security-bugs.html
      As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
    • El reporter sí tuvo tiempo para revisar y mencionar explícitamente distribuciones concretas como Ubuntu/RHEL/SUSE en su sitio web
      Como mínimo, habría sido responsable avisar a los equipos de seguridad de esas distribuciones
    • Cuesta ver como razonable que el reporter haya creado un sitio web que señala explícitamente a Ubuntu, RedHat, Amazon y SUSE, y aun así no les haya avisado
      Tampoco parece creíble que no supiera que esas distribuciones son downstream del equipo del kernel
    • Tal vez no sea un requisito obligatorio, pero creo que todos terminaron sufriendo más porque a los reporters les importaba más la notoriedad que una remediation segura
    • Encontrar cómo reportar este tipo de problemas de seguridad a una distribución Linux es muy fácil
      Sale hasta con una búsqueda en Google: https://share.google/aimode/eihDKXZJy94Z5lC1p
      Cuesta entender que no hayan pensado en eso y hayan dejado a todo el mundo expuesto al exploit; en algunas jurisdicciones incluso parecería razonable considerarlo un delito grave

  • El intercambio más interesante sobre la divulgación está en este enlace
    https://www.openwall.com/lists/oss-security/2026/05/01/3
    Es la respuesta de greg k-h: “no podemos avisar con antelación a nadie, porque entonces tendríamos que avisar a todo el mundo sobre todo. Esa es la única política que los organismos legales y gubernamentales nos han permitido adoptar para poder operar”

    • Me gusta Linux, pero me parece una política absurda

  • Hay que dejar de culpar al reporter y exigir que se arregle el proceso del kernel
    El Linux kernel ya no es un proyecto de juguete, y hay empleados de tiempo completo contratados por varias empresas
    Ellos debieron encargarse de avisar a las distribuciones, no una persona cualquiera

    • Si en una publicación de anuncio, que en la práctica era de marketing, se nombró explícitamente a ciertas distros como afectadas, entonces me parece apropiado y esperable que se les hubiera dado un heads-up antes de hacerlo público
      Probablemente no habría habido tanta crítica si no hubieran incluido menciones como RHEL 14
      No estamos hablando de un investigador individual o del ámbito académico, sino de una empresa de seguridad con un departamento profesional de comunicaciones señalando a maintainers de distros
    • Es cierto que las distribuciones y los desarrolladores del kernel deben comunicarse y moverse rápido ante parches de alta severidad
      Pero como el reporter no esperó a que eso ocurriera, puede que personas reales hayan salido perjudicadas, y esa responsabilidad recae en el reporter
    • Reportar una vulnerabilidad y publicar un exploit potente que cualquiera puede usar son cosas completamente distintas
      Soltarlo al mundo sin avisar antes a las principales distribuciones fue irresponsable

  • Para quienes usan un kernel donde AF_ALG está enlazado directamente y no como módulo, alguien publicó un workaround basado en eBPF: https://github.com/Dabbleam/CVE-2026-31431-mitigation
    Lo estoy ejecutando ahora mismo en producción, mitiga el ataque y hasta ahora no se observan efectos secundarios inesperados

  • Creo que nosuid y probablemente nodev deberían ser opciones de montaje por defecto del filesystem
    /dev ya es un devtmpfs especial, y si hace falta un /dev mínimo en el initrd, entonces el rootfs tmpfs del initrd podría montarse explícitamente con dev y suid
    Permitir que binarios SUID “existan” en cualquier lugar es un riesgo de seguridad enorme
    Si montas un medio de almacenamiento externo, ¿cómo verificas que los binarios SUID dentro de ese block device no sean maliciosos?
    Además, este exploit parece requerir que el usuario que ejecuta el binario SUID también pueda leer ese binario
    No hay razón para que un usuario no root tenga permiso de lectura sobre un binario SUID
    NixOS maneja esto correctamente
    En /nix/store, que es el directorio normal de instalación de paquetes, no hay SUID, y como los paquetes no se filtran fuera de ahí, se puede usar nosuid con seguridad en otros mountpoints
    La única excepción es un directorio de propósito único, /run/wrappers.$hash, que contiene de forma segura únicamente wrappers SUID solo ejecutables

    • Yo también odio suid, pero aquí suid no es el problema esencial
      El bug explotado permite en la práctica un page cache poisoning arbitrario
      A partir de ese punto, la partida ya está perdida, y aunque parchear programas suid puede ser la forma más fácil de obtener una root shell, no es ni de cerca la única
    • El exploit de prueba de concepto solo muestra literalmente un vector de ataque
      Hay muchas otras formas
      Si el objetivo fuera solo bloquear el exploit de demostración, habría métodos más simples como un blacklist, pero eso no lo vuelve más seguro
      Esta vulnerabilidad permite manipular el page cache
      Podrías manipular ld.so para enganchar cualquier system call, cambiar el uid a 0 o elevar privilegios de muchas otras maneras
      El mount point no tiene nada que ver con este problema
      Claro, bloquear suid en áreas escribibles por usuarios y evitar la lectura de archivos suid siempre es buena idea, pero por otras razones
      NixOS tampoco corrige esta vulnerabilidad y es tan vulnerable como las demás distribuciones
    • Si no hay permiso de lectura, no puedes ejecutar el binario, y eso tiene sentido
      Para ejecutar un binario, hay que leerlo desde disco y cargarlo en memoria
      De hecho, si un binario en particular tiene permiso de lectura pero no de ejecución, también puedes ejecutarlo invocando directamente el linker
      Por ejemplo, llamando a /bin/ld.so.1 /path/to/binary, el linker lee y carga el binario y luego salta a su entry point sin hacer una llamada a exec()

  • En el enlace de Bleeping Computer de abajo hay posibles medidas de respuesta mientras se prepara el parche
    https://www.bleepingcomputer.com/news/security/new-linux-cop...

    • Este workaround solo aplica a kernels donde el código afectado fue compilado como módulo
      RHEL, Fedora y Gentoo están configurados para compilar ese código directamente dentro del kernel
      Sin un parche o un cambio de configuración, como insinuó Sam en Gentoo, esas distribuciones seguirán siendo vulnerables
    • En RedHat y sus distribuciones derivadas, el código afectado está compilado estáticamente y no como módulo, así que esta mitigación no funciona

  • NixOS tampoco recibió aviso
    https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

    • Ninguna distribución recibió aviso

  • Hyperbola GNU estuvo a salvo porque todavía usa Python 3.8 por razones políticas y de estabilidad

  • Ubuntu ya publicó un parche, y las pruebas antes y después del parche ya se completaron