1 Punkte von GN⁺ 2025-11-04 | 1 Kommentare | Auf WhatsApp teilen
  • Das X.Org-Projekt hat ein Update veröffentlicht, das mehrere Sicherheitslücken behebt, die in Versionen vor xorg-server 21.1.18 und vor Xwayland 24.1.8 gefunden wurden
  • Die erste Schwachstelle (CVE-2025-62229) ist ein use-after-free-Problem bei der Erstellung der Struktur XPresentNotify, bei dem das Risiko besteht, dass ein Zeiger nach dem Freigeben während der Fehlerbehandlung erneut verwendet wird
  • Die zweite Schwachstelle (CVE-2025-62230) ist ein use-after-free-Problem beim Entfernen von Xkb-Client-Ressourcen, bei dem die Funktion zum Löschen von Ressourcen beim Beenden des Clients auf bereits freigegebene Daten verweist
  • Die dritte Schwachstelle (CVE-2025-62231) ist ein Wertüberlauf in der Funktion XkbSetCompatMap(), bei dem die Summe der Eingabedaten den Bereich von unsigned short überschreiten kann
  • Alle Schwachstellen wurden in xorg-server 21.1.19 und Xwayland 24.1.9 behoben, und X.Org dankte den Meldern und Mitwirkenden an den Korrekturen

Überblick über den X.Org-Sicherheitshinweis

  • X.Org hat am 28. Oktober 2025 einen Hinweis zu mehreren Sicherheitsproblemen veröffentlicht, die in der Implementierung von X Server und Xwayland gefunden wurden
  • Die Probleme wurden in den Versionen xorg-server 21.1.19 und xwayland 24.1.9 behoben
  • Die Schwachstellen wurden von Jan-Niklas Sohn in Zusammenarbeit mit der Trend Micro Zero Day Initiative entdeckt

CVE-2025-62229 — use-after-free in der XPresentNotify-Struktur

  • Bei der Verwendung der X11-Present-Erweiterung kann beim Hinzufügen einer Benachrichtigung nach der Anzeige einer Pixmap im Fehlerfall ein dangling pointer zurückbleiben
    • Dadurch kann später beim Zerstören der Benachrichtigungsstruktur ein use-after-free auftreten
  • Das Problem wurde in Xorg 1.15 eingeführt und in xorg-server 21.1.19 sowie xwayland 24.1.9 behoben
  • Fix-Commit: 5a4286b1

CVE-2025-62230 — use-after-free beim Entfernen von Xkb-Client-Ressourcen

  • Beim Entfernen der Xkb-Ressourcen eines Clients gibt die Funktion XkbRemoveResourceClient() nur die mit dem Gerät verknüpften XkbInterest-Daten frei, jedoch nicht die zugehörigen Ressourcen
    • Dadurch verweist die Funktion zum Löschen der Ressourcen beim Beenden des Clients auf bereits freigegebene Daten, was zu einem use-after-free führt
  • Das Problem wurde in X11R6 eingeführt und in xorg-server 21.1.19 sowie xwayland 24.1.9 behoben
  • Fix-Commits: 99790a2c, 10c94238

CVE-2025-62231 — Wertüberlauf in XkbSetCompatMap()

  • Die Struktur XkbCompatMap speichert einige Werte als unsigned short, prüft jedoch nicht, ob die Summe der Eingabedaten diesen Bereich überschreiten kann
    • Dadurch kann ein Wertüberlauf auftreten
  • Das Problem wurde in X11R6 eingeführt und in xorg-server 21.1.19 sowie xwayland 24.1.9 behoben
  • Fix-Commit: 475d9f49

Danksagung und Verteilung

  • X.Org dankte allen Mitwirkenden, die die Probleme gemeldet und an den Korrekturen mitgearbeitet haben
  • Dem Hinweis sind OpenPGP-Signatur- und Public-Key-Dateien beigefügt
  • Weitere Informationen sind in der xorg-announce-Mailingliste verfügbar

1 Kommentare

 
GN⁺ 2025-11-04
Hacker-News-Kommentare
  • Ich frage mich, wie diese Änderungen auf Basis von X11Libre/xserver funktionieren
    Meinem Verständnis nach behebt man dort die Sicherheitsprobleme, die in X.Org aufgetreten sind
    Da XLibre aber angeblich Tausende von Problemen behoben hat, die auf X.Org-Seite nicht gelöst wurden, wäre es interessant zu wissen, ob das dort bereits entschärft war

    • Auf ihrem GitHub sieht man, dass dieselben drei Änderungen wie bei X.Org am 28. Oktober, also am Tag der Veröffentlichung der Sicherheitsmitteilung, übernommen wurden
      Es war also nicht schon vorher behoben, sondern wurde direkt nach der Ankündigung gepatcht
    • Wenn man sieht, wie viel Arbeit in 5 Monaten in XLibre geflossen ist, wirkt es wie ein ziemlich aktives Projekt
    • Ich halte das Projekt für einen realitätsfernen, fast fantastischen Versuch
      Wenn X.Org vollständig eingestellt würde, hätte es wohl nicht die Kapazität, X11 zu pflegen
    • Ist das nicht der Fork, der sich als „anti-woke“ positioniert?
      Ehrlich gesagt wirkte es auf mich so, als würde eine bestimmte Person persönlichen Frust über einen X-Server-Fork ausleben
  • Solche Schwachstellen zu finden und zu beheben ist gut, aber nicht vertrauenswürdigen Clients zu erlauben, mit dem X-Server zu kommunizieren, ist schon vom Design her riskant
    Besonders wenn es Tcl/Tk-Apps gibt, könnte man sogar direkt Programmbefehle über den X-Server senden

    • In Umgebungen, in denen der X-Server mit höheren Rechten läuft oder auf einem anderen Host ausgeführt wird, kann das zu Privilegieneskalation führen
      X11 hat kaum Sicherheitsmechanismen für Benutzersitzungen, deshalb sollte man besser keine UI-Programme mit geringem Vertrauensniveau ausführen
      Dass es keine Möglichkeit gibt, Tasteninjektion oder Bildschirmaufnahmen zu verhindern, ist eine Grenze des Designs, aber man sollte solche Angriffe nicht unterschätzen
    • Es gibt immer noch die legendären Entwickler, die xorg-Bugs beheben
      Früher hat Alan Coopersmith einen von mir gemeldeten Bug persönlich behoben
      Soweit ich mich erinnere, ging es wohl um ein fehlendes Flag in einem C-Programm
    • 1996 war der Grad der X-Integration von Tk erstaunlich
      Damals konnte man Netscape mit einem MIT Magic Cookie steuern, was rückblickend ziemlich furchteinflößend ist
    • Der send-Befehl von Tk ist gefährlich, aber man kann ihn leicht blockieren, indem man ihn auf einen No-op umbindet
  • Coverity findet solche Arten von Bugs ziemlich gut
    Deshalb frage ich mich, warum ein wichtiges Projekt wie X.Org den kostenlosen Zugang zu diesem Tool nicht nutzt

    • Der Grund ist einfach. Die Leute, die Wayland entwickeln, waren ursprünglich X.Org-Entwickler
      Sie konzentrieren sich jetzt darauf, Motivation für den Wechsel zu schaffen, und wollen ihre Energie nicht für die Pflege des alten Projekts aufwenden
  • Der größte Schmerzpunkt bei Linux ist die Grafik. Wirklich schade

    • Ich denke, dank der Grafik hat Linux auf dem Desktop einen Marktanteil von über 1 % erreicht
      Wenn die Hardware Probleme macht, ist es hart, aber in den meisten Umgebungen laufen Steam-Spiele fast auf nativem Niveau
      Das Problem ist nicht Linux, sondern die Hardware-Seite
    • Xorg ist definitiv komplex und schwer zu handhaben
      Das ist aber nicht nur ein Linux-Problem, sondern wirkt inzwischen eher wie eine Legacy-Technologie
    • Unser Schmerz ist die Grafik ... und Audio ... und WLAN-Unterstützung ...
      Letztlich sind die drei Leiden von Linux Grafik, Audio und WLAN-Hardware-Unterstützung
      Dazu kommt noch die fast religiöse Fixierung auf die Kommandozeile
  • Ich hoffe, man tötet Xorg nicht :(

  • Ich frage mich, ob Fil-C das erste oder dritte Problem hätte verhindern können

    • Meiner Meinung nach wären alle vermeidbar gewesen
  • Ich frage mich, wie Twitter an X.com gekommen ist
    Andersherum: Hätte ein Open-Source-Projekt Twitter.org bekommen können?

    • Ende der 90er fusionierte X.com mit PayPal, und Elon Musk hat die Domain übernommen
  • Grob gesagt ist X11 inzwischen nur noch für alte Spiele oder den Steam-Client übrig geblieben
    Vor allem der Steam-Client ist weiterhin eine 32-Bit-Binärdatei, was es noch problematischer macht

  • Wenn Weston unter Fil-C mit Software-Rendering gut läuft, dürfte auch der X-Server unter Fil-C gut funktionieren
    Fil-C hat den geringsten Overhead bei bitoperationslastigem Code und den höchsten bei pointerlastigem Code
    Ich würde den X-Server eher der ersten Kategorie zuordnen. Bei Weston war es genauso