Mehrere Sicherheitsprobleme in GNU Screen entdeckt

 (openwall.com)
2 Punkte von GN⁺ 2025-05-14 | 1 Kommentare | Auf WhatsApp teilen
  • Bei einer Sicherheitsprüfung von GNU Screen wurden mit Fokus auf Screen 5.0.0 und setuid-root-Installationen lokale Privilegieneskalation, TTY-Hijacking, Informationslecks, Race Conditions beim Signalversand und Abstürze beim Senden von Befehlen festgestellt
  • Das schwerwiegendste Problem, CVE-2025-23395, ermöglicht es logfile_reopen(), benutzerkontrollierte Pfade mit Root-Rechten zu verarbeiten, wodurch sich Root-eigene Dateien an beliebigen Orten anlegen oder Logs an bestehende Dateien anhängen lassen
  • Auch altes Verhalten im Multiuser-Modus erwies sich als problematisch: Attach() setzt TTYs vorübergehend auf 0666, wodurch andere Benutzer lesen, schreiben und Eingaben einschleusen können
  • Das Risiko unterscheidet sich je nach Distribution und Installationsart; Arch Linux und NetBSD 10.1 liefern Screen 5.0.0 als setuid-root aus und sind daher besonders stark von den wichtigsten Schwachstellen betroffen
  • Aktuell wird empfohlen, Screen nicht als setuid-root zu installieren; für die Multiuser-Funktion sind ein vertrauensgruppenbasiertes Opt-in, abgesenkte Standardrechte, begrenzte Privilegienerhöhung und eine Bereinigung von Umgebungsvariablen nötig

Hintergrund der Offenlegung und Patches

  • Im Juli 2024 bat der Upstream-Maintainer von Screen um eine Prüfung der aktuellen Codebasis, die eigentliche Sicherheitsanalyse begann im Januar 2025
  • Dabei wurde in den größeren Änderungen von Screen 5.0.0 ein lokaler Root-Exploit entdeckt, der Distributionen mit setuid-root betrifft
  • Zusätzlich wurden weitere Probleme geringerer Schwere festgestellt; einige betreffen auch Screen 4.9.1 und ältere Versionen, die in vielen Distributionen weiterhin vorhanden sind
  • Die Probleme wurden am 30. April 2025 über die distros-Mailingliste geteilt und am 12. Mai 2025 veröffentlicht
  • Dem Bericht waren Patch-Sammlungen nach Version beigefügt

Screen-Konfiguration und Multiuser-Modus

  • Screen 5.0.0 wurde im August 2024 als großes Upstream-Release veröffentlicht; Arch Linux, Fedora 42 und NetBSD 10.1 liefern diese Version aus
  • Viele Linux- und UNIX-Distributionen verwenden zum Zeitpunkt des Berichts weiterhin Screen 4.9.1
  • Der Multiuser-Modus von Screen erlaubt es, sich bei vorhandenen Berechtigungen an eine Screen-Sitzung anzuhängen, die einem anderen Benutzer gehört
    • Diese Funktion ist nur verfügbar, wenn Screen mit dem setuid-root-Bit installiert ist
    • Da komplexer Screen-Code mit Root-Rechten ausgeführt wird, vergrößert sich die Angriffsfläche
  • Auf den geprüften Systemen installieren Arch Linux, FreeBSD und NetBSD Screen als setuid-root
  • Bei Gentoo Linux wird das setuid-root-Bit gesetzt, wenn das USE-Flag "multiuser" aktiviert ist
  • Einige Distributionen verwenden statt setuid setgid
    • Bei Gentoo Linux ist der Standard setgid-utmp, damit Screen Login-Einträge in der systemweiten utmp-Datenbank anlegen kann
    • Fedora Linux nutzt setgid-screen, damit Screen Sockets in das systemweite Verzeichnis /run/screen legen kann

CVE-2025-23395: Lokaler Root-Exploit in logfile_reopen()

  • CVE-2025-23395 betrifft Screen 5.0.0, wenn es mit setuid-root-Rechten läuft
  • Die Funktion logfile_reopen() senkt beim Verarbeiten benutzerkontrollierter Pfade die Rechte nicht ab
  • Ein nicht privilegierter Benutzer kann dadurch Dateien mit folgenden Eigenschaften an beliebigen Orten anlegen
    • Eigentümer: root
    • Gruppe: die reale Gruppe des aufrufenden Benutzers
    • Dateimodus: 0644
  • Auch bereits existierende Dateien lassen sich missbrauchen
    • Daten, die in das Screen-PTY geschrieben werden, werden an diese Datei angehängt
    • Modus und Eigentümerschaft der bestehenden Datei bleiben unverändert
  • Beim ersten Öffnen der Logdatei senkt Screen die Rechte korrekt ab, doch sobald es entscheidet, dass die Logdatei erneut geöffnet werden muss, wird eine Privilegieneskalation möglich
  • In der Prüfung stolen_logfile() wird logfile_reopen() aufgerufen, wenn die ursprüngliche Logdatei einen Link Count von 0 hat oder sich ihre Größe unerwartet ändert
  • Diese Bedingung kann von einem nicht privilegierten Benutzer absichtlich ausgelöst werden
  • Patch 0001 für Screen 5.0.0 führt bei der Wiedereröffnung der Logdatei wieder eine sichere Dateibehandlung ein
  • Das Problem entstand, als in dem älteren Commit 441bca708bd lf_secreopen() entfernt wurde; diese Änderung war Teil des Releases 5.0.0

CVE-2025-46802: TTY-Hijacking beim Attach an Multiuser-Sitzungen

  • CVE-2025-46802 tritt in der Funktion Attach() auf, wenn das Flag multiattach gesetzt ist
  • Beim Attach an eine Multiuser-Sitzung setzt Screen per chmod() den Modus des aktuellen TTY vorübergehend auf 0666
  • Der TTY-Pfad wird zwar darauf geprüft, unter /dev zu liegen und Bedingungen wie isatty() zu erfüllen, sodass dieses Verhalten allein keinen separaten lokalen Root-Exploit ergibt
  • Das Problem ist jedoch eine Race Condition, weil andere Benutzer das TTY lesen und beschreiben können, solange die Rechte vorübergehend gelockert sind
  • In einem einfachen Test auf Basis der Linux-inotify-API konnte ein Python-Skript bei etwa jedem zweiten oder dritten Versuch das betroffene TTY öffnen
  • Ein Angreifer kann dadurch
    • in das TTY eingegebene Daten abfangen
    • Daten in das TTY injizieren
    • den Benutzer zur Eingabe eines Passworts verleiten
    • Steuersequenzen einschleusen, um das Opfer zu verwirren oder terminalemulatorspezifische Probleme auszunutzen
  • In einigen return-Pfaden von Attach() wird der ursprüngliche TTY-Modus nicht wiederhergestellt
    • zum Beispiel, wenn die Zielsitzung nicht gefunden wurde und das Argument "quiet" gesetzt ist
  • Der Patch entfernt das temporäre chmod()
    • Patch 0001 für Screen 4.9.1
    • Patch 0004 für Screen 5.0.0
  • Kurz vor der Offenlegung stellte sich heraus, dass dieser Patch einige Reattach-Anwendungsfälle beeinträchtigen könnte, diese waren jedoch bereits in Screen 4.9.1 defekt
  • Das Problem existiert mindestens seit Screen-Versionen ab 2005 und betrifft Linux-Distributionen und BSD-Systeme, die Multiuser-Unterstützung mit setuid-root bereitstellen
  • Auch ohne setuid-root ist ein theoretischer Effekt möglich, weil Benutzer die Rechte ihres eigenen TTY ändern dürfen; ohne Root-Rechte setzt Screen das Fortsetzen an fremde Sitzungen jedoch nicht fort

CVE-2025-46803: Weltweit beschreibbare PTYs als Standard in Screen 5.0.0

  • CVE-2025-46803 beschreibt, dass der Standardmodus für von Screen zugewiesene PTYs in Screen 5.0.0 von 0620 auf 0622 geändert wurde
  • Mit diesem Standard kann jeder im System in das Screen-PTY schreiben
  • Sicherheitlich ähnelt dies CVE-2025-46802, allerdings ohne den Aspekt des Informationsabflusses
  • In Screen 4.9.1 war der Standard auf Code-Ebene zwar 0622, durch die autotools-Konfiguration galt jedoch standardmäßig 0620, sodass ein sicherer Standard verwendet wurde
  • In Screen 5.0.0 wurde configure.ac neu geschrieben; dabei verschwand der Standard 0620 auf autoconf-Ebene, und später wurde der Configure-Schalter pty-mode mit dem Standard 0622 erneut eingeführt
  • Release Notes für 5.0.0 wurden nicht gefunden, und es gab nur einige ChangeLog-Einträge; die Änderung des Standardwerts für den PTY-Modus wirkt nicht wie eine bewusste Entscheidung
  • Patch 0002 für Screen 5.0.0 stellt in configure.ac wieder einen sicheren Standard für den PTY-Modus her
    • Zur Anwendung der Änderung ist autoreconf erforderlich
  • Paketbetreuern wird empfohlen, den Configure-Schalter --with-pty-mode=0620 explizit zu übergeben
  • Gentoo Linux und Fedora Linux übergeben ein sicheres --with-pty-mode bereits explizit
  • Arch Linux und NetBSD übergeben diesen Schalter nicht, sodass der neue Standard aktiv ist und die Systeme verwundbar sind

CVE-2025-46804: Offenlegung der Dateiexistenz über Socket-Pfad-Fehlermeldungen

  • CVE-2025-46804 ist ein geringfügiges Informationsleck, das auftritt, wenn Screen mit setuid-root-Rechten läuft
  • Es wurde sowohl in älteren Screen-Versionen als auch in 5.0.0 bestätigt
  • Screen prüft SocketPath mit Root-Rechten und gibt über Fehlermeldungen Pfadinformationen preis, die ein nicht privilegierter Benutzer normalerweise nicht kennen würde
  • Über die Umgebungsvariable SCREENDIR lässt sich etwa ableiten,
    • ob /root/.lesshst eine normale Datei ist
    • ob das Verzeichnis /root/.cache existiert
    • ob der Pfad /root/test nicht existiert
  • Der Patch sorgt dafür, dass bei setuid-root-Installationen nur noch generische Fehlermeldungen ausgegeben werden, wenn der Zielpfad nicht von der realen UID des Prozesses kontrolliert wird
    • Patch 0002 für Screen 4.9.1
    • Patch 0005 für Screen 5.0.0
  • Alle geprüften Distributionen sind betroffen

CVE-2025-46805: TOCTOU-Race-Condition beim Signalversand

  • CVE-2025-46805 ist eine TOCTOU-Race-Condition beim Senden von Signalen an benutzerkontrollierte PIDs im setuid-root-Kontext
  • CheckPid() senkt die Rechte auf die reale Benutzer-ID ab und prüft dann, ob der Kernel das Senden eines Signals an die Ziel-PID erlaubt
  • Das eigentliche Signal wird später über Kill() gesendet, wobei Root-Rechte verwendet werden können
  • Zwischen Prüfung und tatsächlichem Versand kann die zuvor geprüfte PID durch einen anderen privilegierten Prozess ersetzt werden
  • Es könnte auch möglich sein, einen privilegierten Screen-Daemon-Prozess dazu zu bringen, sich selbst ein Signal zu senden
  • Derzeit lassen sich nur SIGCONT und SIGHUP senden, daher dürfte die Auswirkung vor allem in lokalem Denial of Service oder geringfügigen Integritätsverletzungen liegen
  • Das Problem geht auf eine unvollständige Behebung von CVE-2023-24626 zurück
    • Vor dieser Korrektur konnten diese Signale auch ohne Race Condition an beliebige Prozesse gesendet werden
  • Der Patch ändert das Verhalten so, dass auch das eigentliche Signal wie in CheckPid() mit den Rechten der realen UID gesendet wird
    • Patch 0003 für Screen 4.9.1
    • Patch 0006 für Screen 5.0.0
  • Alle geprüften Distributionen sind betroffen

Absturz beim Senden von Befehlen durch strncpy() in Screen 5.0.0

  • In Screen 5.0.0 gibt es ein Problem im Zusammenhang mit strncpy(), das nicht als Sicherheitslücke eingestuft wird, aber vorrangig behoben werden sollte
  • Im Commit 0dc67256 wurden mehrere Aufrufe von strcpy() durch strncpy() ersetzt
  • strncpy() ist keine Funktion für sichere String-Verarbeitung, sondern füllt Puffer fester Länge mit 0 auf und schreibt daher auch nach dem ersten \0-Byte bis zum Ende des Zielpuffers weiter Nullen
  • In der Schleife zur Verarbeitung von Kommandozeilenargumenten in attacher.c wird auch nach der ersten Iteration weiterhin MAXPATHLEN als Zielgröße übergeben
  • Obwohl der Zeiger p bereits erhöht wurde, bleibt die angegebene Größe gleich, sodass nachfolgende strncpy()-Aufrufe \0-Bytes hinter das Ende des Puffers schreiben
  • Auf Arch Linux wurde beim Senden von mehr als einem Befehlsargument an eine laufende Screen-Sitzung in Builds mit aktiviertem _FORTIFY_SOURCE folgender Fehler beobachtet
    • *** buffer overflow detected***: terminated
    • Aborted (core dumped)
  • Ohne _FORTIFY_SOURCE kann ein sichtbarer Fehler ausbleiben, und auch mit -fsanitize=address muss nicht zwingend ein Fehler erscheinen
  • Der Aufrufer kann zwar die MAXPATHLEN Bytes hinter dem Puffer cmd mit Nullen überschreiben, doch da direkt dahinter ein weiterer Puffer writeback[MAXPATHLEN] liegt, wird eine vorteilhafte Ausnutzung für Angreifer als unwahrscheinlich eingeschätzt
  • Patch 0003 für Screen 5.0.0 ersetzt strncpy() durch snprintf() und übergibt die verbleibende Größe des Zielpuffers korrekt
  • Alle Distributionen, die Screen 5.0.0 ausliefern, sind betroffen

Auswirkungen nach Distribution

System Screen-Version Besondere Rechte Auswirkungen
Arch Linux 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10 4.9.0 keine teilweise 3.b
Ubuntu 24.04.2 4.9.1 keine teilweise 3.b
Fedora 42 5.0.0 setgid-screen teilweise 3.b, 3.f
Gentoo 4.9.1 setgid-utmp, bei gesetztem multiuser-USE-Flag setuid-root teilweise 3.b
openSUSE TW 4.9.1 keine teilweise 3.b
FreeBSD 14.2 4.9.1 setuid-root 3.b, 3.d, 3.e
NetBSD 10.1 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
OpenBSD 7.7 4.9.1 keine teilweise 3.b

Bedenken zum setuid-root-Design und Empfehlungen

  • Im Multiuser-Modus von Screen spielen drei UIDs eine Rolle
    • effektive UID 0 für privilegierte Operationen
    • reale UID des Benutzers, der die Sitzung erstellt hat
    • reale UID des Benutzers, der sich an die Sitzung anhängt
  • Der aktuelle Screen-Code scheint strukturell kaum geeignet, diese Trennung sauber abzubilden
  • Eine von root erstellte Multiuser-Sitzung von Screen „senkt die Rechte ab“ auf die reale UID 0 des Sitzungserstellers, wodurch faktisch keine Rechteabsenkung stattfindet
  • Im Zuge des Refactorings von Screen 5.0.0 wurde langjährig vorhandene Sicherheitslogik beschädigt, woraus CVE-2025-23395 und CVE-2025-46803 entstanden
  • Vor weiteren Refactorings wird eine Testsuite benötigt, mit der sich die Sicherheitseigenschaften der Implementierung verifizieren lassen
  • Entwickler, die setuid-root-Binärdateien betreuen, müssen die Risiken dieses Bereichs verstehen
  • Screen läuft weiterhin mit erhöhten Rechten und senkt sie nur selektiv für als riskant betrachtete Operationen ab
  • Robuste setuid-root-Programme sollten standardmäßig mit abgesenkten Rechten laufen und nur für tatsächlich privilegierte Operationen Rechte erhöhen
  • Im setuid-root-Kontext ist Logik nötig, die nur ausdrücklich erlaubte Umgebungsvariablen beibehält und den Rest entfernt
  • Umgebungsvariablen wie PATH sollten auf vertrauenswürdige Systemverzeichnisse beschränkt werden
  • Derzeit wird empfohlen, nicht nur Screen 5.0.0, sondern auch ältere 4.9-Versionen nicht als setuid-root zu installieren
  • Als Alternative könnte die Multiuser-Funktion als Opt-in angeboten werden, sodass nur Mitglieder einer vertrauenswürdigen Gruppe eine Multiuser-Version von Screen ausführen können

Koordination der Offenlegung und Upstream-Status

  • Im Februar 2025 wurden die Probleme vertraulich an das Screen-Upstream-Projekt gemeldet und eine koordinierte Offenlegung vorgeschlagen
  • Upstream zeigte Interesse daran, die Probleme bis zur Veröffentlichung vertraulich zu halten, und teilte mit, dass dafür ein bis zwei Monate nötig seien
  • Rund einen Monat später begannen Aktivität und Patch-Diskussionen auf Upstream-Seite, diese verliefen jedoch nicht ausreichend produktiv
  • Als sich die maximale Embargofrist von 90 Tagen näherte, gab es keine weitere Kommunikation; in der Zwischenzeit hatten Distributionen wie NetBSD bereits auf Screen 5.0.0 aktualisiert und waren damit vollständig von CVE-2025-23395 betroffen
  • Es wurde der Eindruck gewonnen, dass Upstream mit der Screen-Codebasis nicht ausreichend vertraut ist und die gemeldeten Sicherheitsprobleme nicht vollständig versteht
  • Upstream wollte eine frühere Veröffentlichung, obwohl einige Probleme noch ungelöst waren; daraufhin wurde ein Entwurf rasch über die distros-Mailingliste verteilt
  • Anschließend entwickelte SUSE fehlende Korrekturen selbst und passte zudem Patches an und dokumentierte sie, die bei Upstream nur als Entwürfe diskutiert worden waren
  • Mit ausreichender dedizierter Upstream-Kapazität hätte das Verfahren der koordinierten Offenlegung nach Einschätzung in etwa zwei Wochen abgeschlossen werden können
  • Das Screen-Upstream-Projekt scheint unter Mangel an Personal und Fachwissen zu leiden, was angesichts eines weit verbreiteten Open-Source-Dienstprogramms besorgniserregend ist

Wichtige Termine

  • 2024-07-01: Bitte um Prüfung durch Upstream übermittelt
  • 2025-01-08: Beginn der Sicherheitsanalyse
  • 2025-02-07: Vertrauliche Meldung an Screen-Upstream und Vorschlag zur koordinierten Offenlegung
  • 2025-02-11: Vertraulicher Bug im GNU-Savannah-Bugtracker erstellt
  • 2025-04-30: Entscheidung zur CVE-Vergabe und Teilung des Entwurfs über die distros-Mailingliste
  • 2025-05-07: Fertige Patches für Screen 4.9.1 und 5.0.0 mit distros-Mailingliste und Upstream geteilt
  • 2025-05-12: Bericht im Blog und auf der oss-security-Mailingliste veröffentlicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-14
Kommentare auf Hacker News

  • Ich wusste nicht, dass Screen so einen Mehrbenutzermodus hat, aber vermutlich ist das der Grund, warum Tools wie tmate möglich sind.
    Mit den passenden Zugangsdaten kann man sich an eine Screen-Session anhängen, die einem anderen Nutzer gehört; diese Funktion sei nur möglich, wenn Screen als setuid-root installiert ist.
    Deshalb frage ich mich, ob tmux von derselben Art Schwachstelle betroffen ist.

    • tmux betrifft das nicht, weil es Unix-Domain-Sockets verwendet.
      Ich weiß nicht, warum screen hier den setuid-Ansatz gewählt hat; Root-Rechte scheinen dafür überhaupt nicht nötig zu sein.
      Weiter unten im Beitrag gibt es die plausible Erklärung, dass die aktuellen screen-Entwickler mit der Codebasis nicht vollständig vertraut sind. Falls das stimmt, könnte setuid-root der einfachste Weg gewesen sein, die Funktion zum Laufen zu bringen.
    • Das ist eine ziemlich großartige Funktion.
      In Schulungen habe ich jedem Teilnehmer ein Login-Konto auf meinem Laptop gegeben, die SSH-Shell auf screen -x beschränkt und über die Zugriffskontrolllisten von screen dafür gesorgt, dass jeder nur sein eigenes Fenster nutzen konnte.
      Während der Übungen konnte ich als Besitzer der screen-Session den Bildschirm jedes Teilnehmers auf den Projektor legen, sodass die ganze Klasse die Ergebnisse sehen konnte.
      Es würde mich allerdings nicht wundern, wenn es viele Sicherheitslücken gibt.
    • Genau, screen -x

  • Unter Debian wird GNU screen nicht mit setuid-root-Rechten installiert.

    • Das Paket in Debian Stable, also bookworm, ist so alt, dass es von der 5.0.0-Schwachstelle nicht betroffen ist.
      Früher hat es mich immer gestört, dass Debian bei Softwareversionen hinterherhinkt, aber inzwischen nutze ich nur noch für ein paar Apps, bei denen ich nicht auf wirklich alte Software angewiesen sein möchte – etwa Browser –, andere Paketquellen und komme ansonsten mit den alten Paketen gut zurecht.
    • Unter Slackware 15 zeigt /usr/bin/screen auf screen-4.9.0, und die ausführbare Datei ist ebenfalls nicht suid.
    • Bei Gentoo ist es genauso.
      Allerdings ist unter Gentoo für die Gruppe utmp SETGID gesetzt; welche Auswirkungen das hat, weiß ich nicht genau.
    • Unter Fedora scheint es setuid-root zu sein.

  • Der gerenderte Blogbeitrag ist hier: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • Ich habe dem Autor von GNU Screen einmal eine E-Mail geschrieben, weil die Datei-Logging-Funktion nicht ordentlich dokumentiert war: http://www.zoobab.com/screenrc
    GNU braucht ein besseres Issue-Tracking-System.

    • Es gab ein Q&A mit dem Autor von Tmux, und schon vor etwa 16 Jahren beschwerte er sich über mangelnde Dokumentation.
      https://undeadly.org/cgi?action=article&sid=20090712190402
    • Im GNU-screen-Handbuch ist das ausführlich dokumentiert: https://www.gnu.org/software/screen/manual/screen.html#Log
    • Bei vielen alten Projekten gibt es das Problem, dass Issues in den endlosen Tiefen nicht indexierter Mailinglisten verschwinden.
      Es ist berechtigt, Discord dafür zu kritisieren, dass solche Informationen unzugänglich werden, aber IRC, das manche Projekte noch nutzen, ist praktisch doppelt so schlimm.
      Ich wünschte, solche Projekte würden zu Gitea, Forgejo, Codeberg, GitLab, GitHub oder Ähnlichem umziehen, um relevante Inhalte an einem Ort zu bündeln und Auffindbarkeit herzustellen.

  • Zellij ist als moderne Alternative zu screen und tmux ziemlich gut, hat hervorragende Defaults und eine gut auffindbare UI.
    Empfehlenswert für alle, die das Verhältnis von Aufwand zu Nutzen bei Terminal-Multiplexern bisher fragwürdig fanden.
    https://zellij.dev
    https://github.com/zellij-org/zellij

    • Ich habe es vor ein paar Jahren ausprobiert, und es war ziemlich rund.
      Im Vergleich zu tmux war die Latenz aber deutlich spürbar, und ich nutze weiterhin tmux.
      Damals war ich ohnehin auf einer Verbindung mit Latenz unterwegs, daher war ich vielleicht etwas empfindlich.
    • Als ich Zellij zuletzt gesehen habe, wirkte es wie ein großartiges neues Projekt im Multiplexer-Ökosystem, unterstützte aber keinen rein tastaturbasierten Kopieren/Einfügen-Mechanismus.
      Diese Funktion nutze ich sehr intensiv, ohne sie geht es für mich nicht; bis sie hinzugefügt wird, muss ich bei tmux bleiben.
    • Es ist gut, aber ich mag screen wirklich, und die Befehle sind längst im Muskelgedächtnis.
      Ich nutze es seit über 20 Jahren.

  • Ich bin überrascht, dass Upstream hier beteiligt war.
    Vor ungefähr fünf Jahren kam ich traurig zu dem Schluss, dass die Entwicklung von GNU screen komplett zum Stillstand gekommen sei; ich frage mich, ob das doch nicht mehr stimmt.
    Ich weiß nicht, ob screen noch immer die Funktion hat, ein neues Fenster hinzuzufügen, ohne sich an eine bestehende screen-Session anzuhängen.

    • Upstream hat das SUSE-Team gebeten, einen Blick darauf zu werfen.
      Es scheint an Entwicklerkapazität zu fehlen, und möglicherweise hat Upstream nicht die nötige Expertise für eine ordentliche Wartung.
      Falls das stimmt, ist das traurig. Ich weiß, dass es tmux und andere Alternativen gibt, aber viele Menschen nutzen Screen seit sehr langer Zeit, und es ist schade, wenn ein Tool langsam verfällt.
    • Es heißt, dass die Kommunikation mit Upstream schwierig sei und man derzeit keine Details zu den von dort gelieferten Bugfixes und Releases habe.
      Sie haben zwar um eine Sicherheitsprüfung gebeten, konnten den Kontakt aber offenbar schwer aufrechterhalten; die ganze Lage kenne ich nicht.
    • Die Beteiligung besteht wohl höchstens darin, es als setuid-root auszuliefern.
      Distributionen, die es so konfigurieren, sind verwundbar; Distributionen, die es nicht tun, sind es nicht.
      Ich würde das als sehr oberflächliche Beteiligung sehen. Wenn Upstream zu langsam ist, patchen die Distributionen.
    • Dass die Entwicklung von GNU-Tools zum Stillstand kommt, ist nicht unbedingt traurig – von Bugfixes natürlich abgesehen.
      Im Grunde kann man es als Zeichen für ein fertiges Tool verstehen.
    • In Open Source gibt es das Problem der Trägheit, wenn eine Software endet und andere Software als Ersatz entsteht.
      Es gibt keinen unmittelbaren Anreiz zum Wechsel, weil es eben kein Update, sondern ein Umstieg ist.
      Umgekehrt ist es auch schlecht, wenn jemand die Marke einer bestehenden Software kauft und sie wie bei Audacity in etwas völlig anderes verwandelt.
      Deshalb scheint es keine gute Lösung zu geben.

  • Gerenderte Version: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • tmux ist, wenn ich mich richtig erinnere, seit OpenBSD 4.6 Teil des Basissystems und wurde bzw. wird auditiert.
    Eine gute Option für alle, die eine etwas sicherere Alternative wollen.

    • Screen wieder erwähnt zu sehen, erinnert mich daran, wie ich irgendwann zu tmux gewechselt bin und screen danach vergessen habe.

  • Das beobachtete Verhalten gab es mindestens seit 2005 in Screen-Versionen, war also schon sehr lange ein Antipattern und wurde auch von Tools wie rkhunter behandelt.
    Trotzdem war screen meiner Erinnerung nach schon in den 90ern setuid root.

  • Wie viele Entwickler betreiben tatsächlich die beliebtesten Open-Source-Tools?
    Und wie viel Geld steckt in den Branchen, die diese Tools nutzen?