GNU Screen affected with multiple vulnerabilities >>>

A comprehensive security audit by the SUSE Security Team has uncovered a collection of serious flaws in the widely-used terminal multiplexer GNU Screen, including one that enables local privilege escalation to root. These issues affect both the latest Screen 5.0.0 release and the more commonly deployed Screen 4.9.x, depending on distribution configurations.

While GNU Screen is a cornerstone utility in many UNIX-like systems for managing terminal sessions, the findings reveal significant risks—particularly for platforms where Screen is installed with setuid-root privileges to support multi-user features.
The security report details multiple vulnerabilities, including a local root exploit and issues related to TTY hijacking, PTY permissions, file existence tests, and race conditions.


CVE-2025-23395: Local Root via logfile_reopen()
The most severe of the issues allows local privilege escalation. In Screen 5.0.0, the logfile_reopen() function fails to drop elevated privileges when reopening user-defined log files, enabling attackers to write arbitrary data to root-owned files.
“Unprivileged users can create files in arbitrary locations with root ownership… All data written to the Screen PTY will be logged into this file,” the report warns.
The vulnerability is triggerable on-demand by manipulating the link count of a log file to force a reopen, and has been confirmed on Arch Linux and NetBSD, where Screen is installed setuid-root.

CVE-2025-46802: TTY Hijacking via Race Condition
Another major flaw involves a race condition in Attach() during multi-user session reattachment. When invoked, Screen temporarily sets the terminal device’s mode to 0666, exposing the user’s TTY to read/write access by any process on the system.
“We managed to open affected TTYs every second or third attempt using a simple Python script,” SUSE reported.
Although originally intended to enable communication between session daemons, this chmod-based approach creates a dangerous window for keystroke interception or command injection.

CVE-2025-46803: World-Writable PTYs by Default
Screen 5.0.0 also changed the default PTY mode to 0622, making them world-writable. This allows any user to write to any PTY managed by Screen, reproducing some aspects of the TTY hijacking vulnerability—now as a default behavior.
Distributions like Arch Linux and NetBSD are affected unless they explicitly override the compile-time configuration.

CVE-2025-46804: File Existence Information Leak
Screen can be tricked into revealing the existence and type of files owned by root through misuse of the SCREENDIR environment variable, disclosing whether paths are directories, files, or inaccessible.

CVE-2025-46805: Signal Handling Race Condition
In an incomplete fix for CVE-2023-24626, Screen still allows race conditions in its signal-sending logic. Attackers could send signals like SIGHUP or SIGCONT to unintended processes by exploiting the time-of-check/time-of-use (TOCTOU) window between permission checks and actual signal delivery.
Buffer Overflow Due to Misuse of strncpy()
While not assigned a CVE, a non-exploitable buffer overflow in Screen 5.0.0 could lead to crashes when users attempt to send commands to an active Screen session with multiple arguments. The bug stems from an improper replacement of strcpy() with strncpy().
This has been observed in Arch Linux, where the application crashes with FORTIFY_SOURCE protections enabled.
SUSE strongly advises against installing Screen with setuid-root privileges at this time. The report notes that many of these issues arise from outdated privilege management models and recent regressions introduced during code refactoring in 5.0.0.
“There is furthermore a broad design issue in Screen: it runs with elevated privileges all the time, and only selectively drops privileges for operations that are considered dangerous. For a robust setuid-root program this should be the other way around: privileges should be dropped by default and only raised for operations that actually require elevated privilege,” SUSE recommends.
They recommend shipping multi-user support as opt-in, possibly restricted to a trusted group, and propose broader architectural changes to ensure safe privilege handling.

Affected Versions