GNU Screen gehört zu den bekanntesten Terminal-Multiplexern, die auf vielen Unix- und Linux-Systemen eingesetzt werden. Die Software ermöglicht es Nutzern, mehrere Shell-Sitzungen innerhalb eines einzigen Terminalfensters zu verwalten, Sitzungen zu trennen und später wieder anzuhängen, und unterstützt komplexe Multi-User-Szenarien. Trotz seiner Popularität und langjährigen Entwicklungsgeschichte zeigt sich nun eine Vielzahl von sicherheitsrelevanten Schwachstellen, die im Kontext von Screen-Versionen 4. 9. 1, 5. 0. 0 und setuid-root Installationen besonders kritisch sind. Die Analyse dieser Sicherheitsproblematik zeigt, wie komplex und schwierig die Programmierung sicherheitskritischer Systemtools ist und wie wichtig eine sorgfältige Wartung und geprüfte Updates sind. Bereits seit Juli 2024 beschäftigen sich Sicherheitsexperten intensiv mit dem Code von GNU Screen, nachdem die Upstream-Betreuer um eine Sicherheitsüberprüfung baten.
Anfang 2025 wurden dann mehrere gravierende Schwachstellen identifiziert, die eine lokale Root-Eskalation ermöglichen, Zugriffsrechte auf Terminalgeräten unsicher handhaben und sensible Informationen preisgeben können. Ein prominentes Problem betrifft das Verhalten der Funktion logfile_reopen() in Screen 5. Obwohl Screen beim Anlegen eines Logfiles noch seine Privilegien korrekt zurücksetzt, versäumt die Funktion bei dessen erneuter Öffnung das Herabsetzen der Rechte. Dies ermöglicht es Angreifern, eine schreibbare Logdatei an beliebigen Stellen im Dateisystem anzulegen oder umzuleiten. So lässt sich etwa eine Logdatei durch einen symbolischen Link ins System verändern und mit Root-Rechten beschreiben. Theoretisch kann auf diesem Wege eine Root-Kommandoausführung erzwungen werden, beispielsweise durch das Einfügen von Befehlen in Startskripte oder kritische Konfigurationsdateien. Besonders gefährdet sind Distributionen wie Arch Linux und NetBSD, die Screen 5.
0 mit setuid-root-Rechten ausliefern. Fedora hingegen nutzt Screen mit setgid-Rechten, wodurch der Angriffsspielraum geringfügig eingeschränkt ist, aber nicht vollständig entfällt. Gentoo weist eine differenzierte Situation auf: Während die stabile Version Screen 4. 1 ausliefert, die nur bedingt verwundbar ist, kann die instabile Version 5. 0 mit aktivierter „multiuser“ USE-Flagge ebenfalls zum Risiko werden. Neben dieser Root-Eskalation wurde eine weitere Schwachstelle im Attach()-Prozess von Multi-User-Sitzungen erkannt. Dabei werden temporär die Zugriffsrechte des aktuellen TTY-Geräts auf 0666 gesetzt, was praktikabel erscheint, um verschiedenen Nutzerprozessen Zugriff zu gewähren, allerdings eine temporäre Angriffsmöglichkeit durch Race-Conditions eröffnet. Während dieses Zeitfenster können andere lokale Nutzer das Terminal öffnen, Daten auslesen oder Eingaben injizieren.
Dies stellt nicht nur eine Gefahr für vertrauliche Eingaben wie Passwörter dar, sondern kann durch manipulierte Terminalsteuersequenzen auch weitere Folgeschäden verursachen. Darüber hinaus wurde aufgedeckt, dass in der Screen-Version 5. 0 standardmäßig Pseudo-Terminals (PTYs) mit dem Modus 0622 anstatt 0620 erstellt werden. Dies erlaubt fremden Nutzern, an Screen angeschnittene PTYs zu beschreiben, wodurch weitere Missbrauchsmöglichkeiten entstehen. Historisch war der Standardmodus mit 0620 bewusst restriktiv gewählt, um unbefugte Schreibzugriffe zu verhindern. Die Änderung scheint unbeabsichtigt und wurde durch den Mangel an klarer Release-Dokumentation begleitet. Eine weitere Schwachstelle betrifft Informationslecks durch differenzierte Fehlermeldungen beim Umgang mit Socket-Pfaden, welche insbesondere bei setuid-root Installationen durch den missbräuchlichen Einsatz der SCREENDIR-Umgebungsvariable ausgenutzt werden können.
So lassen sich gezielt Informationen über das Vorhandensein oder Zugriffsrechte auf bestimmte Verzeichnisse oder Dateien ermitteln. Dies kann Angreifern wertvolle Hinweise zur gezielten Vorbereitung von Attacken liefern. Auch Race Conditions bei der Signalübermittlung an Prozesse wurden gefunden. In der derzeitigen Implementierung prüft Screen die Berechtigung zum Signalisieren eines Prozesses unter den eingeschränkten Rechten des tatsächlichen Nutzers, sendet das Signal dann aber ggf. mit root-Rechten. Während der Verzögerung zwischen Überprüfung und Signal senden könnte sich das Signalziel ändern oder auf einen privilegierten Prozess umgelenkt werden. Obwohl die Auswirkungen sich bislang auf lokale Denial-of-Service oder geringfügige Integritätsverletzungen beschränken, verdeutlicht dies die notwendige Sorgfalt im Umgang mit privilegiertem Code. Weitgehend nicht sicherheitskritisch, aber dennoch relevant ist ein Problem im Umgang mit Eingabeparametern, das bei Screen 5.
0 durch den fehlerhaften Einsatz von strncpy() zu Pufferüberläufen und Abstürzen führen kann. Dies wurde durch ungünstige Quellcodeänderungen verursacht, die das potenzielle Risiko einer Speicherverletzung mit sich bringen. Neben der technischen Analyse wirft die Offenlegung dieser Sicherheitslücken auch ein Licht auf die Herausforderungen bei der Koordination zwischen Sicherheitsforschern und Open-Source-Projekten. Kommunikation mit dem upstream des GNU Screen erwies sich als schleppend und wenig effektiv. Trotz des Interesses seitens der Entwickler war es nicht möglich, alle gefundenen Bugfixes zeitnah in die offiziellen Releases zu integrieren. Dies führte zu der Entscheidung, selbst verantwortliche Patches zu erstellen und mit Distributionen direkt zu teilen, um den Schutz der Nutzer zu gewährleisten. Das gesamte Verfahren verdeutlichte, dass der Screen-Entwicklungsprozess mit Personal- und Ressourcenengpässen kämpft.
Vor dem Hintergrund des hohen Verbreitungsgrades und der sicherheitstechnisch sensiblen Einsatzart eines setuid-root-Programms sind diese Defizite alarmierend. Anhand der betroffenen Distributionen lässt sich feststellen, dass vor allem Arch Linux und NetBSD durch den Einsatz von Screen 5. 0 im setuid-root-Modus besonders gefährdet sind. Fedora und Gentoo stellen mit ihren jeweiligen Konfigurationen teilweisen Schutz her, müssen jedoch weiterhin wachsam bleiben. Andere Distributionen wie Debian, Ubuntu oder OpenBSD setzen ältere Versionen ein, bei denen zumindest einige Schwachstellen wie das temporär unsichere TTY-Chmod vorhanden sind. Aufgrund des weitreichenden Sicherheitspotenzials empfiehlt sich für Systemadministratoren ganz klar, GNU Screen nicht mit setuid-root zu verwenden, sofern es nicht unbedingt notwendig ist. Wenn die Mehrbenutzerfunktionalität gebraucht wird, ist eine explizite opt-in Konfiguration mit Einschränkungen auf vertrauenswürdige Nutzergruppen ratsam.
Zugleich sollten Administratoren die veröffentlichen Patches zeitnah einspielen und bei eigenen Screen-Installationen überprüfen, ob Compilation mit sicherheitsfördernden Optionen sowie explizite Übernahme sicherer Konfigurationsvarianten, wie die PTY-Modus-Einstellung auf 0620, erfolgt. Für Entwickler bzw. das GNU Screen Projekt ergibt sich die dringende Empfehlung, eine grundlegende Überarbeitung der Berechtigungslogik anzugehen. Die Praxis, das Programm mit Root-Rechten dauerhaft laufen zu lassen und nur selektiv Privilegien zu senken, birgt erhebliche Risiken und erschwert die sichere Wartung. Vielmehr sollte das Prinzip der geringstmöglichen Rechtevergabe verfolgt werden, bei dem nur für genau definierte Operationen temporär erhöhte Rechte erlangt werden. Zudem ist die Einführung eines robusten Testframeworks zur automatisierten Erkennung von Sicherheitsproblemen wünschenswert.
Abschließend verweist der gesamte Fall auf die allgemeine Bedeutung sicherheitsbewusster Programmierung, auch bei etablierten Open-Source-Projekten mit langer Geschichte. Gerade bei Programmen, die mit Systemprivilegien operieren, bedarf es einer kontinuierlichen und qualitätsgesicherten Wartung, um gefährliche Sicherheitslücken rechtzeitig zu erkennen und zu beheben. Nutzer von GNU Screen sind daher gut beraten, solche Veröffentlichungen aufmerksam zu verfolgen und Sicherheitsupdates möglichst umgehend einzuspielen, um ihr System vor potentiellen Angriffen zu schützen.
