Mehrere Sicherheitsprobleme in GNU Screen entdeckt

• In GNU Screen 5.0.0 und bei setuid-root-Installationen wurden schwerwiegende Sicherheitslücken entdeckt
• Zu den wichtigsten Problemen zählen lokale Root-Rechteausweitung, TTY-Hijacking und weltweit beschreibbare PTYs
• Zahlreiche Linux- und UNIX-Distributionen sind teilweise oder vollständig betroffen
• Es werden temporäre Patches bereitgestellt, und viele Distributionen müssen vorrangig Maßnahmen ergreifen
• Im setuid-root-Design von Screen selbst besteht ein grundlegendes Sicherheitsrisiko

---

1. Einführung

• Im Juli 2024 begann die Sicherheitsprüfung, nachdem der Upstream-Maintainer von Screen um Code-Review gebeten hatte
• Früher waren keine besonderen Probleme gefunden worden, diesmal wurde jedoch in Screen 5.0.0 bei setuid-root-Konfiguration eine schwerwiegende Schwachstelle zur Root-Rechteausweitung entdeckt
• Zusätzlich wurden mehrere kleinere Sicherheitslücken bestätigt, die auch frühere Versionen (4.9.1 usw.) betreffen
• Dem Bericht sind Patch-Sets für die jeweiligen Versionen (4.9.1, 5.0.0) beigefügt
• Enthalten sind unter anderem Screen-Konfiguration und Version je Distribution, die wichtigsten Schwachstellen, Entwicklungsrisiken rund um setuid-root, Empfehlungen zur Härtung, Probleme im Offenlegungsprozess und eine Impact-Matrix

2. Überblick über Screen-Konfiguration und Versionen

• Im August 2024 wurde Screen 5.0.0 veröffentlicht und in Arch Linux, Fedora 42 und NetBSD 10.1 aufgenommen
• 5.0.0 enthält zahlreiche Refactorings, von denen einige auf Code basieren, der seit mehr als zehn Jahren existiert
• Einige Schwachstellen wurden neu in 5.0.0 eingeführt, andere bestehen auch in älteren Versionen (4.9.1 usw.)
• Die meisten Distributionen verwenden weiterhin 4.9.1
• Der Mehrbenutzermodus von Screen ist nur verfügbar, wenn es als setuid-root installiert ist; durch die Code-Komplexität vergrößert sich die Angriffsfläche erheblich
• Unter den großen Distributionen installieren Arch Linux, FreeBSD und NetBSD Screen als setuid-root; bei Gentoo ist setuid-root nur mit dem USE-Flag „multiuser“ möglich

3. Details zu den Sicherheitsproblemen

3.a) Lokaler Root-Gewinn über logfile_reopen() (CVE-2025-23395)

• Wenn Screen 5.0.0 als setuid-root ausgeführt wird, erstellt die Funktion logfile_reopen() Dateien anhand eines vom Benutzer eingegebenen Pfads, ohne die Privilegien abzulegen
• Angreifer können beliebige root-eigene Dateien erzeugen, um Terminaldaten aufzuzeichnen und dies auszunutzen
• Auch bereits vorhandene Dateien können missbraucht werden, etwa durch das Einschleusen von Code in privilegierte Shell-Skripte
• Arch Linux und NetBSD 5.0.0 sind vollständig verwundbar, Fedora und bestimmte Gentoo-Umgebungen teilweise
• Der Patch stellt eine sichere Dateibehandlung wieder her; die konkrete Auswirkung unterscheidet sich je nach Distribution

3.b) TTY-Hijacking beim Verbinden mit Mehrbenutzersitzungen (CVE-2025-46802)

• In der Funktion Attach() werden bei aktiviertem multiattach-Flag die Berechtigungen des TTY vorübergehend auf 0666 gesetzt
• Dadurch wird durch eine Race Condition Lese-/Schreibzugriff auf dieses TTY durch einen dritten Benutzer möglich
• Es bestehen Risiken wie das Mithören von Eingaben, Datenmanipulation und Passwortdiebstahl
• Es gibt auch Codepfade, in denen die TTY-Berechtigungen nicht wiederhergestellt werden
• Der Patch entfernt die chmod 666-Manipulation; einige Reconnect-Use-Cases könnten dadurch nicht mehr funktionieren, liefen aber ohnehin bereits nicht korrekt

3.c) Unsichere Standardberechtigungen für PTYs (CVE-2025-46803)

• In 5.0.0 wurden die Standardberechtigungen für PTYs von 0620 auf 0622 (weltweit beschreibbar) geändert
• Dadurch steigt das potenzielle Sicherheitsrisiko, insbesondere weil alle Benutzer auf andere PTYs schreiben können
• Diese Änderung scheint versehentlich eingeführt worden zu sein; der Patch behebt das Problem durch die Wiederherstellung des sicheren Compile-Standards (0620)
• Arch Linux und NetBSD sind die Hauptbetroffenen

3.d) Informationsleck über Dateiexistenz durch Socket-Fehlermeldungen (CVE-2025-46804)

• Über die Umgebungsvariable SCREENDIR und Fehlermeldungen lässt sich mit Root-Rechten feststellen, ob reale Dateien/Verzeichnisse existieren
• Es handelt sich um ein kleines Informationsleck, das jedoch in allen setuid-root-Installationen ein Risiko darstellt

3.e) TOCTOU-Race-Condition beim Senden von Signalen (CVE-2025-46805)

• Durch das Zeitfenster zwischen den Funktionen CheckPid() und Kill() besteht das Risiko, dass mit Root-Rechten Signale an einen anderen als den beabsichtigten PID gesendet werden
• Erlaubt sind hauptsächlich nur SIGCONT, SIGHUP usw., daher ist die Auswirkung begrenzt; möglich sind jedoch Denial-of-Service (DoS) oder leichte Integritätsverletzungen

3.f) Overflow beim Senden von Befehlen durch fehlerhafte strncpy()-Verwendung

• In 5.0.0 führt die fehlerhafte Verwendung von strncpy() zu einem Buffer Overflow und Programmabstürzen
• Ohne korrekten Patch wird beim Senden von Befehlen Speicher hinter MAXPATHLEN überschrieben, was zu einem Ausfall des Dienstes führen kann
• Es ist kein Sicherheitsproblem, muss aber aus Stabilitätsgründen schnell behoben werden

4. Zusätzliche Risiken der setuid-root-Implementierung

• Im Mehrbenutzermodus wurde eine mangelhafte Logik zur Verarbeitung mehrerer Benutzer-UIDs festgestellt
• Die Logik zum Ablegen von Privilegien ist im setuid-root-Zustand nicht vollständig
• In von Root erzeugten Sitzungen werden effektive Privilegien nicht zuverlässig abgesenkt, wodurch insgesamt ein hohes Risiko besteht

5. Allgemeine Empfehlungen zur Härtung

• Im Zuge umfangreicher Refactorings wurde ein Zusammenbruch bestehender Sicherheitslogik festgestellt
• Wegen der Eigenschaften von setuid-root-Binärdateien besteht die Notwendigkeit, Security-Test-Suites einzuführen und jede Verarbeitung von Dateisystemen und Umgebungsvariablen konservativ zu gestalten
• Insbesondere wird die vollständige Ausführung als setuid-root nicht empfohlen; Mehrbenutzerfunktionen sollten nur per Opt-in für vertrauenswürdige Gruppen erlaubt werden
• Umgebungsvariablen (PAH usw.) sollten zwingend nur auf vertrauenswürdige Pfade gesetzt werden dürfen

6. Probleme im Koordinationsprozess der Offenlegung

• Der Koordinationsprozess mit dem Upstream verlief ineffizient, wodurch sich Patch-Entwicklung und Veröffentlichung verzögerten
• Wegen unzureichendem Codeverständnis und fehlender Kapazitäten auf Upstream-Seite war eine enge Reaktion schwierig
• Schließlich trieben die Distributionen die Patch-Entwicklung voran, und der Bericht wurde gemäß dem abgestimmten Zeitplan veröffentlicht
• Auch ein Mangel an Wartungs- und Pflegekapazität im Screen-Projekt selbst wurde deutlich

7. Impact-Matrix

• Arch Linux (5.0.0, setuid-root): von allen Schwachstellen 3.a, 3.b, 3.c, 3.d, 3.e, 3.f betroffen
• Debian/Ubuntu und viele weitere Distributionen: 3.b (teilweise betroffen)
• Fedora 42 (5.0.0, setgid-screen): 3.b (teilweise betroffen), 3.f betroffen
• Gentoo (4.9.1, setgid-utmp): 3.b (teilweise betroffen), bei unstable ebuild + USE-Flag multiuser gleiche Auswirkungen wie 5.0.0
• FreeBSD 14.2 (4.9.1, setuid-root): 3.b, 3.d, 3.e betroffen
• NetBSD 10.1 (5.0.0, setuid-root): von 3.a, 3.b, 3.c, 3.d, 3.e, 3.f betroffen
• OpenBSD 7.7 (4.9.1): 3.b (teilweise betroffen)
• openSUSE TW: 3.b (teilweise betroffen)

8. Zeitplan

• 2024-07-01: Anfrage für Code-Review vom Upstream erhalten
• 2025-01-08: Beginn des Reviews
• 2025-02-07: Schwachstellen vertraulich an den Upstream gemeldet, koordinierte Offenlegung angefragt
• 2025-02~04: Patch-Diskussionen, Zeitplan wegen Problemen mit der Embargo-Phase neu abgestimmt
• 2025-05-12: Veröffentlichung dieses Berichts und offizielle Bekanntgabe

9. Referenzlinks

• GNU Savannah [Screen-Projektseite]
• openSUSE Bugzilla, zugehörige Patches, referenzierte CVEs sowie Links zu Bugreports und Dokumentation

[GN⁺]

Hacker-News-Kommentare

• Es gibt in Screen einen Multi-User-Modus, der es mehreren Nutzern erlaubt, sich gemeinsam mit einer Session zu verbinden; ich denke, dass dadurch Tools wie tmate möglich werden, und ich frage mich, ob tmux dieselbe Schwachstelle hat
  • tmux verwendet Unix-Domain-Sockets; ich verstehe nicht, warum Screen den setuid-Ansatz gewählt hat, denn Root-Rechte scheinen nicht nötig zu sein. Laut der Erklärung im TFA sieht es so aus, als hätten sich die aktuellen Screen-Entwickler für setuid-root entschieden, weil sich die Funktion damit einfacher umsetzen ließ und sie die Codebasis nicht vollständig durchdringen.
  • Diese Funktion ist wirklich großartig: In Trainingssessions habe ich jedem Teilnehmer auf meinem Laptop ein eigenes Login-Konto gegeben und die ssh-Shell auf screen -x <bestimmtes Benutzerfenster> beschränkt, sodass die Teilnehmer nur die Fenster nutzen konnten, die in dieser Screen-ACL erlaubt waren. Ich habe dann per Projektor nacheinander die Bildschirme der Teilnehmer kontrolliert und gezeigt. Dass das voller Sicherheitslücken ist, überrascht mich allerdings nicht.
  • Ich habe schon einmal den Befehl screen -x verwendet.
• Unter Debian wird GNU screen nicht mit setuid-root-Rechten installiert
  • Das Debian-Stable-(bookworm-)Paket ist zu alt und daher nicht von der 5.0.0-Schwachstelle betroffen. Früher mochte ich es nicht, dass Debian bei Softwareversionen so langsam war, aber heute nutze ich für ein paar Anwendungen, die ich brauche, separat Paketquellen für neuere Versionen, und den Rest verwende ich problemlos auch in älteren Versionen.
  • Bei Gentoo ist es genauso, dort ist aber SETGID für die utmp-Gruppe gesetzt. Ich weiß nicht genau, was das bedeutet.
  • Unter Slackware 15 hat screen kein suid.
  • Unter Fedora scheint es mit setuid installiert zu sein.
• Hier ist die gerenderte Version des Blogposts: https://security.opensuse.org/2025/05/12/screen-security-issues.html
• Ich habe dem Autor eine E-Mail geschickt, weil die Dokumentation zur Logdatei-Schreibfunktion von GNU Screen mangelhaft ist. Ich finde, GNU braucht ein besseres Issue-Tracking-System. Relevantes Material: http://www.zoobab.com/screenrc
  • Es gab auch ein Q&A mit dem tmux-Autor; schon vor 16 Jahren wurde über die schlechte Dokumentation geklagt. Relevantes Material: https://undeadly.org/cgi?action=article&sid=20090712190402
• Das beobachtete Verhalten gibt es in Screen seit 2005; als Anti-Pattern wurde es lange von Tools wie rkhunter abgedeckt, und ich bin ziemlich sicher, dass screen schon in den 90ern setuid-root war.
• Es überrascht mich, dass sich upstream (das offizielle Entwicklerteam) diesmal beteiligt hat. Vor etwa fünf Jahren war ich traurig, weil es so aussah, als sei die Entwicklung von GNU screen komplett zum Stillstand gekommen. Ich frage mich, ob das immer noch so ist. Außerdem frage ich mich, ob man Screen ein neues Fenster hinzufügen kann, ohne sich an die Session anzuhängen.
  • Upstream hat das SUSE-Team um ein Review gebeten. Es fehlt an Entwicklungskapazität, und aktuell scheint es nicht gut gepflegt zu werden. Falls das so ist, wäre das bedauerlich. Es gibt zwar Alternativen wie tmux, aber viele Leute verwenden Screen seit Langem; schade, wenn Tools auf diese Weise veralten.
  • Die gesamte Beteiligung bestand darin, es als setuid-root auszuliefern. Nur Distributionen, die es so konfigurieren, sind verwundbar; alle anderen sind nicht betroffen. Wenn offizielle Patches langsam kommen, patchen Distributionen es direkt selbst.
  • Ich halte es nicht unbedingt für schlecht, wenn die Entwicklung von GNU-Tools aufhört (Bugfixes ausgenommen). Das kann auch ein Zeichen dafür sein, dass der Funktionsumfang ausreichend fertig ist.
  • Die Kommunikation mit upstream ist schwierig, daher gibt es wohl keine detaillierten Informationen zu Bugfixes oder Releases. Es wurde zwar um ein Security-Review gebeten, aber die Kontaktaufnahme scheint schwierig zu sein.
  • Bei Open Source gibt es das Problem der Trägheit: Selbst wenn eine Software am Ende ist und ein Ersatz auftaucht, fehlt oft der Anreiz, sofort umzusteigen. Umgekehrt gibt es auch Fälle, in denen nur die Marke übernommen und alles durch etwas völlig anderes ersetzt wird, wie bei Audacity. Eine gute Lösung gibt es nicht.
• Link zur gerenderten Version: https://security.opensuse.org/2025/05/12/screen-security-issues.html
• Ich frage mich, wie viele Entwickler all diese populären Open-Source-Tools tatsächlich selbst verwenden und wie viel Geld in den Bereichen bewegt wird, in denen diese Tools eingesetzt werden.
• Soweit ich mich erinnere, war tmux ab 4.6 Teil der OpenBSD-Standardinstallation und wurde auditiert; für Menschen, die mehr Wert auf Sicherheit legen, ist es eine gute Alternative.
  • Als ich die Erwähnung von screen gesehen habe, musste ich daran denken, dass ich früher auf tmux umgestiegen war und dann aus Gewohnheit durcheinanderkam, weil ich versehentlich kein screen mehr benutzt habe.
• Es ist interessant, dass screen und setuid erwähnt werden. Ich habe screen einmal mit chmod u+s versehen, um ein seltsames Problem zu lösen. Dass man so etwas tun muss, fühlte sich merkwürdig an. Später stellte sich jedoch heraus, dass screen Funktionen hat, die von setuid abhängen, und dass manche Systeme es standardmäßig so ausliefern. Als ich dann u+s gesetzt hatte, las screen statt meiner ~/.screenrc die ~/.screenrc von root ein (ich habe das damals als Workaround akzeptiert). Ich vermute, dass sich die setuid-Unterstützung je nach Build von screen unterscheiden kann.
  • So funktioniert setuid grundsätzlich: Wenn man bei einer Binärdatei das spezielle Bit setzt, bedeutet das, dass sie immer als der angegebene Benutzer ausgeführt werden soll.