Screen ist ein beliebtes und leistungsfähiges Terminal-Multiplexer-Programm, das es Nutzern ermöglicht, mehrere konsolenbasierte Sitzungen innerhalb eines einzigen Terminalfensters zu verwalten. Die Software wird in zahlreichen Linux- und UNIX-Distributionen eingesetzt und dient als unverzichtbares Werkzeug für Entwickler, Systemadministratoren und Power-User. Trotz seiner Popularität hat die SUSE Security Team Blog im Jahr 2025 eine Reihe von schwerwiegenden Sicherheitsproblemen in Screen aufgedeckt, die vor allem die Versionen 4.9.1 und 5.
0.0 betreffen. Die entdeckten Schwachstellen haben Auswirkungen auf die Integrität, Vertraulichkeit und Verfügbarkeit von Systemen und sollten von allen Nutzern und Distributionen, die Screen einsetzen, ernst genommen werden. Zudem rücken die Probleme die Bedeutung eines verantwortungsvollen Umgangs mit setuid-root Programmen in den Fokus. Das kritische Problem begann mit der Veröffentlichung von Screen 5.
0.0 im August 2024. Trotz umfangreicher Refactorings, die teilweise auf mehr als ein Jahrzehnt alter Codebasis fußten, konnte erstmals eine lokale Root-Exploitable-Schwachstelle identifiziert werden. Diese ermöglicht es einem nicht privilegierten Benutzer, durch eine Sicherheitslücke in der Funktion logfile_reopen() eine Datei an einem beliebigen Ort mit Root-Rechten anzulegen. Diese log-Datei fungiert als Ziel, in das sämtliche Eingaben auf der Pseudo-Terminal-Schnittstelle (PTY) geschrieben werden.
Ein Angreifer kann diese Datei manipulieren, etwa schadhaften Code in eine systemkritische Datei einschleusen, der beim nächsten Systemstart oder Benutzer-Login ausgeführt wird. Besonders problematisch ist, dass betroffene Distributionen wie Arch Linux und NetBSD die Screen-Version 5.0.0 mit gesetztem setuid-root Bit ausliefern, wodurch die Schadsoftware mit erhöhten Rechten ausgeführt werden kann. So wurde beispielsweise in Arch Linux die setuid-root-Berechtigung aufgrund der Risiken wieder entfernt.
Der exploit kann auch dazu benutzt werden, Sicherheits- und Integritätsmechanismen zu umgehen, indem Systemkonfigurationsdateien verfälscht oder wichtige Logdateien manipuliert werden. Das Multi-User-Feature von Screen, das die gemeinsame Nutzung von Sessions durch verschiedene Benutzer erlaubt, erhöht die Komplexität und damit auch die Angriffsfläche. Hier wurde eine weitere gravierende Schwachstelle in der Attach-Funktion entdeckt, die bei Mehrbenutzer-Sitzungen temporär die Rechte des ursächlichen TTY-Gerätes auf 666 (also lesbar und schreibbar für alle Benutzer) setzt. Trotz korrekter Prüfung des TTY-Pfads, um Missbrauch zu verhindern, entsteht durch den zeitweiligen Wechsel des Dateimodus eine gefährliche Race Condition. Dadurch können Angreifer in sehr kurzen Zeitfenstern auf fremde Eingaben zugreifen, diese abfangen oder manipulieren.
Dieser Angriff ermöglicht beispielsweise das Auslesen vertraulicher Passworte oder das Einschleusen von Steuerbefehlen, die die Terminalkommunikation beeinflussen. Das Risiko besteht seit mindestens 2005 und betrifft somit eine Vielzahl von Distributionen, insbesondere wenn Screen als setuid-root installiert ist. Auch wenn einige Fehlpfade dieses Problem verschärfen, ist es grundsätzlich ein langjähriges Sicherheitsproblem im Code. Ein weiteres bedeutsames Sicherheitsrisiko ergibt sich aus der unsicheren Standardeinstellung zur Erzeugung von PTYs in Screen 5.0.
0. Historisch lag der Standardmodus für die erstellten Pseudo-Terminals bei 0620, was Schreibrechte ausschließlich auf den Eigentümer und dessen Gruppe beschränkte. In der aktuellen Version wurde der Standard aus unerklärlichen Gründen auf 0622 geändert, was eine weltweite Schreibbarkeit der PTYs zulässt. Das bedeutet, dass beliebige Nutzer auf fremde PTY-Sitzungen schreiben können, was wiederum Missbrauch möglich macht, etwa zum Abhören oder Stören von Terminalkommunikationen. Distributoren wie Gentoo und Fedora umgehen dieses Problem durch explizite Konfigurationen, während Arch Linux und NetBSD davon betroffen sind.
Die Änderung des Modus ist vermutlich unbeabsichtigt und stellt einen erheblichen Sicherheitsrückschritt dar, der durch Patches wieder behoben werden kann. Neben diesen Kernproblemen gibt es kleinere, aber relevante Sicherheitslücken und Fehlfunktionen. So können Fehlermeldungen über fehlerhafte Socketpfade von unprivilegierten Benutzern ausgelesen werden, was zu einer gezielten Informationsgewinnung (Information Leak) über das Dateisystem führt. Angreifer können so herausfinden, ob bestimmte Verzeichnisse oder Dateien existieren, etwa durch manipulierte Umgebungsvariablen wie SCREENDIR. Diese Erkenntnisse können in späteren Angriffen verwendet werden, um gezielter vorzugehen.
Auch im Bereich Signalübertragung an Prozesse gibt es erhebliche Schwachstellen. Es wurde eine Race Condition im Ablauf festgestellt, mit der ein Angreifer unter setuid-root-Kontext Signale an andere Prozesse senden kann, ohne vorher die entsprechenden Rechte überprüft zu haben. Dabei wird das tatsächliche Signal mit erhöhten Rechten ausgeführt, obwohl die Prüfung bereits mit heruntergesetzten Benutzerrechten erfolgte. Dies eröffnet Angriffsflächen für DoS-Attacken oder stört die Integrität von Prozessen. Die Problematik resultiert aus einer unvollständigen Korrektur eines früheren CVEs und betrifft sowohl die 4.
9.1 als auch die 5.0.0 Versionen. Ein weiteres Problem, das keine unmittelbare Sicherheitsgefährdung darstellt, aber dennoch schwerwiegende Stabilitätsprobleme verursachen kann, ist die fehlerhafte Verwendung von strncpy(), einer Funktion zur Zeichenkettenkopie.
In Screen 5.0.0 kam es vor, dass Mehrfachaufrufe von strncpy() in einem Puffer unabsichtlich zu Buffer-Overflows mit nachfolgendem Programmabsturz führen. Dieses Problem wird offenbar durch eine ungenaue Längenbegrenzung hervorgerufen, bei der der Zielpuffer mehrmals überschrieben wird. Der Fehler ist besonders problematisch, wenn Kommandos an laufende Screen-Sitzungen gesendet werden, was in der Praxis zu Abstürzen und einem Denial-of-Service-Szenario führen kann.
Erfreulicherweise sind keine aktiven Exploits bekannt, die sich zu einer Privilegieneskalation nutzen lassen. Die verheerende Kombination aller dieser Probleme zeigt exemplarisch, wie riskant setuid-root Programme sein können, insbesondere wenn eine komplexe und kaum geprüfte Codebasis ihnen seit Jahren zugrunde liegt. Die Art, wie Screen mit Privilegien umgeht, ist ein grundlegendes Designproblem. Screen läuft standardmäßig permanent mit Root-Rechten, die nur temporär und selektiv abgelegt werden. Dieses Vorgehen erhöht massiv die Angriffsfläche, da Fehler in Privilegienabsenkungen ausgenutzt werden können.
Ein sicherheitsbewusstes Design sollte andersherum funktionieren, indem Privilegien standardmäßig abgelegt und nur bei zwingendem Bedarf erhoben werden. Auch die Handhabung von Umgebungsvariablen, Zugriffsrechten und Dateisystemoperationen müsste restriktiver und überprüfter erfolgen, um Missbrauch vorzubeugen. In der Praxis betrifft die Auswahl der Installation mit setuid-root Bit maßgeblich die Verwundbarkeit. Während einige Distributionen wie Arch Linux und NetBSD Screen mit setuid-root ausliefern, setzen andere wie Fedora auf eine Setgid-Konfiguration, die mit weniger Rechten operiert und dadurch einige Risiken einschränkt. Gentoo bietet eine flexible Wahlmöglichkeit, bei der das setuid-root Feature nur optional über einen USE-Flag aktiviert wird.
Die Wahl der Konfiguration beeinflusst also entscheidend, ob die zahlreichen Schwachstellen aktiv ausnutzbar sind. Die Koordination der Entdeckung und Behebung dieser Schwachstellen war eine weitere Herausforderung. Der SUSE Security Team Blog beschreibt Kommunikationsprobleme mit dem Screen Upstream, der erst nach fast drei Monaten mit Bugfixes reagierte. Lange Inaktivitätsphasen und ein Mangel an Know-how bei den Entwicklern führten dazu, dass bis zur Patching-Phase viele Distributionen bereits anfällige Versionen auslieferten. Letztendlich war es die Sicherheitsexpertengruppe selbst, die die notwendigen Patches erstellte, dokumentierte und an die Distributionen weitergab, um die gravierenden Risiken abzumildern.
Diese Situation zeigt das Grundproblem mangelnder Ressourcen und Expertise in der Open-Source-Entwicklung wichtiger Infrastruktursoftware. Die empfohlenen Maßnahmen für Nutzer und Paketersteller sind folglich eindeutig: Screen sollte aktuell nicht als setuid-root Binary installiert werden. Wenn die Multi-User-Funktionalität benötigt wird, sollte dies nur opt-in und mit restriktiver Zugangskontrolle erfolgen, zum Beispiel durch Gruppenmitgliedschaft. Zudem sollten Pakete die korrekten sicheren Konfigurationsoptionen verwenden, etwa die explizite Setzung des PTY-Modus auf 0620. Das schnelle Einspielen der Veröffentlichung von Screen 5.
0.1, die alle genannten Fehler adressiert, ist dringend angeraten. Auch sollten Nutzer ihre Systeme auf Updates prüfen, Patches zeitnah einspielen und Systemzugriffsrechte kritisch hinterfragen. Der Fall Screen verdeutlicht eindrucksvoll, wie wichtig eine laufende und qualifizierte Betreuung von essenzieller Software ist, die mit erhöhten Rechten läuft. Sicherheitsreviews müssen regelmäßig und gründlich durchgeführt werden, besonders bei Programmen mit einem historischen Codefundament und komplexem Privilegienmanagement.
Die Priorisierung von Privilegienminimierung, sichere Standardkonfigurationen, strenge Zugriffsprüfungen und allgemeine Robustheit im Design sind unerlässlich, um kritische Sicherheitslücken zu vermeiden. Systeme sollten nie anfällig gemacht werden für potenzielle Root-Ausnutzungen, insbesondere durch lokale Nutzer. Für Administratoren und routinemäßige Anwender ist die wichtigste Erkenntnis aus den Screen-Schwachstellen die Wachsamkeit beim Einsatz von setuid-root Software. Eigenständige Sicherheitsbewertungen, ein umsichtiges Update-Verhalten und vor allem die Vermeidung unnötiger Privilegien sind entscheidend für die Sicherheit von Serversystemen und Arbeitsumgebungen. Zwar bietet Screen nach wie vor wertvolle Funktionen, aber erst die sorgfältige und sichere Implementierung garantiert einen gefahrlosen Betrieb in Mehrbenutzerumgebungen.
