1 puntos por GN⁺ 2025-11-04 | 1 comentarios | Compartir por WhatsApp
  • El proyecto X.Org anunció una actualización que corrige varias vulnerabilidades de seguridad encontradas en versiones anteriores a xorg-server 21.1.18 y Xwayland 24.1.8
  • La primera vulnerabilidad (CVE-2025-62229) es un problema de use-after-free durante la creación de la estructura XPresentNotify, donde existe el riesgo de reutilizar un puntero después de haber sido liberado durante el manejo de errores
  • La segunda vulnerabilidad (CVE-2025-62230) es un problema de use-after-free durante la eliminación de recursos de cliente Xkb, donde la función de borrado de recursos puede referenciar datos ya liberados al cerrarse el cliente
  • La tercera vulnerabilidad (CVE-2025-62231) es un problema de desbordamiento de valor en la función XkbSetCompatMap(), donde la suma de los datos de entrada puede exceder el rango de unsigned short
  • Todas las vulnerabilidades fueron corregidas en xorg-server 21.1.19 y Xwayland 24.1.9, y X.Org expresó su agradecimiento a quienes reportaron y contribuyeron a las correcciones

Resumen del aviso de seguridad de X.Org

  • X.Org publicó el 28 de octubre de 2025 un aviso sobre múltiples problemas de seguridad encontrados en las implementaciones del servidor X y Xwayland
  • Estos problemas fueron corregidos en las versiones xorg-server 21.1.19 y xwayland 24.1.9
  • Las vulnerabilidades fueron descubiertas por Jan-Niklas Sohn en colaboración con Trend Micro Zero Day Initiative

CVE-2025-62229 — use-after-free en la estructura XPresentNotify

  • Al usar la extensión X11 Present, si ocurre un error durante el proceso de agregar una notificación después de mostrar un pixmap, puede quedar un dangling pointer
    • Esto puede provocar un use-after-free más adelante al destruir la estructura de notificación
  • Este problema fue introducido en Xorg 1.15 y corregido en xorg-server 21.1.19 y xwayland 24.1.9
  • Commit de corrección: 5a4286b1

CVE-2025-62230 — use-after-free al eliminar recursos de cliente Xkb

  • Al eliminar los recursos Xkb de un cliente, la función XkbRemoveResourceClient() solo libera los datos XkbInterest conectados al dispositivo, pero no libera los recursos relacionados
    • Como resultado, al cerrarse el cliente, la función de borrado de recursos referencia datos ya liberados y se produce un use-after-free
  • Este problema fue introducido en X11R6 y corregido en xorg-server 21.1.19 y xwayland 24.1.9
  • Commits de corrección: 99790a2c, 10c94238

CVE-2025-62231 — desbordamiento de valor en XkbSetCompatMap()

  • La estructura XkbCompatMap almacena algunos valores como unsigned short, pero no verifica si la suma de los datos de entrada puede exceder ese rango
    • Esto puede provocar un desbordamiento de valor
  • Este problema fue introducido en X11R6 y corregido en xorg-server 21.1.19 y xwayland 24.1.9
  • Commit de corrección: 475d9f49

Agradecimientos y distribución

  • X.Org expresó su agradecimiento a todas las personas que reportaron el problema y participaron en la corrección
  • El aviso incluye una firma OpenPGP y un archivo de clave pública adjuntos
  • Más información disponible en la lista de correo xorg-announce

1 comentarios

 
GN⁺ 2025-11-04
Opiniones en Hacker News
  • Me pregunto cómo funcionan estos cambios en una base de X11Libre/xserver
    Según entiendo, están corrigiendo los problemas de seguridad que aparecieron en X.Org
    Pero como XLibre dice haber corregido miles de problemas que no se han resuelto del lado de X.Org, da curiosidad si esto ya estaba mitigado

    • Si miras su GitHub, los mismos tres cambios que en X.Org se aplicaron el 28 de octubre, o sea el día en que salió el aviso
      No era algo que ya estuviera corregido; lo parchearon justo después del anuncio
    • XLibre parece un proyecto bastante activo, viendo todo lo que han hecho en 5 meses
    • Creo que ese proyecto es un intento más bien fantasioso y poco realista
      Si X.Org se detiene por completo, no parece que tengan la capacidad de mantener X11
    • ¿No es ese el proyecto que se bifurcó con una postura de “anti-woke”?
      Si soy sincero, parecía más que cierta persona estaba expresando frustraciones personales a través de un fork del servidor X
  • Está bien encontrar y corregir este tipo de vulnerabilidades, pero permitir que clientes no confiables se comuniquen con el servidor X es algo riesgoso por diseño
    Sobre todo si hay apps de Tcl/Tk, incluso se pueden enviar comandos de programa directamente a través del servidor X

    • En entornos donde el servidor X corre con más privilegios o en otro host, esto puede convertirse en una vulnerabilidad de escalación de privilegios
      Como X11 casi no tiene mecanismos de seguridad para la sesión del usuario, es mejor no ejecutar programas de interfaz con poca confianza
      No hay forma de impedir la inyección de teclas o la captura de pantalla; es una limitación del diseño, pero no se deberían subestimar estos ataques
    • Todavía hay desarrolladores legendarios que siguen arreglando bugs de xorg
      Hace tiempo Alan Coopersmith me arregló personalmente un bug que reporté
      Creo recordar que era un problema de una bandera faltante en un programa en C
    • En 1996, el nivel de integración de Tk con X era impresionante
      En ese tiempo podías controlar Netscape con una MIT magic cookie, y pensándolo hoy da bastante miedo
    • El comando send de Tk es peligroso, pero se puede bloquear fácilmente reasignándolo como no-op
  • Coverity encuentra muy bien este tipo de bugs
    Pero me pregunto por qué un proyecto tan importante como X.Org no aprovecha el acceso gratuito a esa herramienta

    • La razón es simple. Quienes desarrollan Wayland eran originalmente desarrolladores de X.Org
      Ahora están enfocados en crear motivación para una nueva transición, y no quieren gastar energía manteniendo un proyecto viejo
  • El mayor dolor de Linux son los gráficos. Qué lástima, la verdad

    • Yo diría que gracias a los gráficos Linux ya pasó del 1% de cuota de escritorio
      Cuando el problema es el hardware sí se complica, pero en la mayoría de los entornos los juegos de Steam corren casi a nivel nativo
      El problema no es Linux, sino el hardware
    • Xorg definitivamente es complejo y difícil de manejar
      Pero esto no es algo exclusivo de Linux; más bien ya se siente como una tecnología heredada
    • Nuestro dolor son los gráficos... y el audio... y el soporte de wifi...
      Al final, los tres dolores de Linux son gráficos, audio y soporte de hardware wifi
      Y además, una fijación con la línea de comandos que es casi religiosa
  • Ojalá no maten Xorg :(

  • Me pregunto si Fil-C habría podido evitar el primer o el tercer problema

    • Yo diría que todos se podrían haber evitado
  • Me pregunto cómo fue que Twitter se quedó con X.com
    ¿Habría podido un proyecto de código abierto quedarse con Twitter.org en sentido contrario?

    • A finales de los 90, X.com se fusionó con PayPal, y Elon Musk se quedó con el dominio
  • En términos generales, X11 ahora básicamente sigue existiendo por los juegos viejos o por el cliente de Steam
    En particular, el cliente de Steam sigue siendo un ejecutable de 32 bits, lo que lo vuelve aún más problemático

  • Viendo que Weston corre bien en Fil-C con renderizado por software, parece que el servidor X también debería funcionar bien en Fil-C
    Fil-C tiene la menor sobrecarga en código centrado en operaciones de bits, y la mayor en código centrado en seguimiento de punteros
    Creo que el servidor X se parece más al primero. Weston también era así