Multiple Security Issues in GNU Screen

screen has a lot of architectural baggage that can be traced back to its initial 1987 comp.sources.unix/mod.sources versions in some cases. Being set-UID to the superuser is one of them. See the doco for screen as it was posted in volume 10:

https://sources.vsta.org/comp.sources.unix/volume10/screen/

In the EPEL versions of screen, I am seeing the setgid bit set only. I am guessing that later versions setuid to root?

  $ ll /usr/bin/screen
  -rwxr-sr-x. 1 root screen 495816 Feb  3  2022 /usr/bin/screen

  $ rpm -q screen
  screen-4.8.0-6.el9.x86_64

CVE-2025-46802 can impact earlier releases, but all the other vulnerabilities are for the latest.

screen has used setuid root for multiuser for at least 20 years. Used to use it in multiuser for remote pair programming.

I guess I'm glad that I switched to tmux ages ago.

The problem isn't with the use of `screen -x ...` itself, but rather if `ls -l "$(which screen)"` returns something like `-rwsr-xr-x 1 root root ... /usr/bin/screen`, where the `s` in the fourth position indicates the setuid bit is set. That means the screen binary runs with root privileges.

Related... https://bugzilla.mozilla.org/show_bug.cgi?id=1966096

If you're running Firefox on Debian please make sure you manually update it since the package repo's been down for a while. I filed a 'support' ticket first ( https://support.mozilla.org/en-US/questions/1510388 ) since it seemed to be the proper place, but no one seems to look at those.

If one is in group utmp, one can mess with the login accounting database: the table of currently active logins, the log of log-ons/log-offs, and the table of per-user last logins.

https://jdebp.uk/FGA/unix-login-database.html

The login accounting system that Linux-based operating systems have inherited from Unix really has never reconciled its initial real-terminal-login-only superuser-managed design with the fact that non-superuser programs that allocate pseudo-terminals (e.g. any local terminal emulator, NeoVIM, tmux, screen) want to (over)write entries for those pseudo-terminals in the login accounting database to make the output of the "who" command (and its ilk) more complete.

The best approach I've seen was to re-think the idea; have the pseudo-terminal-using programs run entirely unprivileged and use a client-server model where only the server actually has access to the database files.

Laurent Bercot did this. It fixes many holes, including that the log of log-ons/log-offs is made truly append-only (modulo superuser access to the underlying files). But it has the same architectural problem that any client in the group can overwrite any currently active login record if it knows the record ID, which by design (and the Single Unix Specification) there's an API for enumerating.

* https://skarnet.org/software/utmps/

Both the BSDs and M. Bercot have improved the situation with pututxline(), but it's still not out of the woods yet.

On Fedora it is setgid screen, not root.

Likewise in Arch.

I wonder if there is some selinux policy to reduce the attack surface

Tmux has been in OBSD base side several releases and documented since the first one.

Looks like a tech-debt ridden large piece of software that new developers just can't understand.

If that's the case, it's not really about it being "understaffed". Instead, it's doomed to rot until it's replaced of rewritten. There's no scenario where more maintainers will help, except for marginally delaying it.

The good news is that there are almost perfect replacements out there, and most of them are leaner.

TFA says upstream asked for the review.

screen didn't even have vertical splits until maybe 5 or 10 years ago. After tmux was already a solidly reliable replacement with vertical splits for years.

Not quite in this case. Tmux was started by someone who wanted to update screen with new features but wasn’t able to bend the code that far. I say this not out of spite or meanness, as I used screen for many happy years, but I’d say it’s less complete and more abandoned. It still has maintainers but it seems to me that they’re more “keep the lights on” than actively developing it.

Whether constant development is necessary or not largely depends on the surface area of your tool, both in terms of formal APIs it uses and external data formats and services.

Seems like a prime target for Jia Tan.

Yep, from the timeline it looks like lack of communication (and maybe also capabilities/resources/time/will, not sure) [0]

  0: https://security.opensuse.org/2025/05/12/screen-security-issues.html#8-timeline

> Though conversely, when someone buys the trademark for an existing piece of software, and replaces it with something entirely different, like what happened with Audacity, that's also bad. So there's no good solution.

I've followed the Audacity situation over the last few years. Before the Muse Group bought the rights to the trademarks and took over development, Audacity development had pretty much stagnated.

The new developers did not replace it with something entirely different. What they did was fix longstanding bugs and add new features/enhancements (and changing the way some things work, for better or worse). Sure, they introduced new bugs here and there with the new features/enhancements, but last I checked they fixed those. And yes, they could have done a better job at marking new versions as "beta" rather than pushing them out as stable releases (old hands know to avoid a new version until a couple minor versions later). That's really my biggest gripe with their development/release process.

The good solution is rock-solid, backwards compatible APIs on all levels. That way the work to maintain software would be much lower, making it possible to focus on doing some rare bug-fixing only. In open source in particular this should be a no-brainier, instead of all projects ruining things for each other by ignoring backwards compatibility.

Isn't this what distros are for? So e.g. Debian could decide to replace screen with tmux, possibly with some sort of compatibility package that takes all the same command line arguments as screen but uses tmux under the hood. (I've used screen very little and have never used tmux so I'm not sure if that would make sense in this context).

I personally haven't noticed that, but we all have different sensitivity levels to such things. Have you tried it more recently? A couple years ago is ancient in its lifespan. I'd be curious to see if it still feels sluggish to you.

(Not a dev, just another end user.)