Multiple security issues in GNU Screen

Original Article ↗ Hacker News Discussion ↗

Setuid-root design and security issues

  • Core concern is Screen’s multi-user mode requiring a setuid-root binary, massively increasing attack surface for complex code.
  • Several commenters were unaware this feature existed; others used it heavily for shared debugging, training, and pair programming.
  • Some argue using setuid without fully understanding the codebase is especially bad; others note Screen’s design dates from the 1980s/1990s when setuid was common.
  • Multi-user mode is praised as powerful but now widely seen as a serious security liability.

Distro configurations and affectedness

  • Impact varies by distribution and build:
    • Some distros ship Screen setuid-root (or setgid to a special group), enabling multi-user mode and related vulnerabilities.
    • Others (Debian, Slackware, some Gentoo/Arch setups) ship Screen without setuid and are unaffected by the worst bugs, though specific CVEs differ by version/build.
  • Links to an openSUSE matrix clarify which versions and builds are affected.
  • Some distros (e.g., RHEL) have effectively deprecated Screen in favor of tmux, though it may linger in extra repositories.

Alternatives: tmux, zellij, and minimal tools

  • Many commenters long ago switched to tmux, noting:
    • No need for setuid; uses Unix domain sockets.
    • Audited in some OS bases; considered more modern and maintainable.
    • Some still prefer Screen for serial-port support and specific behavior; tmux’s server/session/window/pane model confuses a few users.
  • zellij is highlighted as a modern, more discoverable Rust-based alternative, though some report past latency and missing fully keyboard-driven copy/paste.
  • Minimal tools (dtach, abduco+dvtm, mtm) are recommended by those who equate security with very small codebases, though they have terminal capability limitations.

Project health, tech debt, and migration

  • Upstream reportedly requested the security review but appears understaffed and hard to reach; Screen is seen as “bitrotting” yet still widely used.
  • Some argue Screen’s architecture is so dated/complex that it’s effectively doomed; others warn against “rewrite from scratch” thinking.
  • Suggestions include:
    • Distros replacing Screen with tmux or a “tmux-as-screen” compatibility wrapper.
    • Keeping Screen only for niche features like serial console support.

Mailing lists and tooling / usability debates

  • Side discussion on mailing lists: praised for openness, federation, and longevity; criticized for poor web UX, accessibility issues, and difficult search.
  • Several note older projects (including GNU tools) bury issues on lists instead of using modern forge-based issue trackers, hurting discoverability and maintenance.