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

Edit: Yes, Screen 5.0.0.

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.

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

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

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.

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).

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

GIT promised to be "Non-proprietary, Decentralized" but still does not have a built-in issue tracker :-)

I wasn't criticizing the use of them, I just find it fascinating that we still use them. They'll probably still be around in some form in another 3 decades.

I don’t think GitHub adds that much over using and contributing to software. I generally prefer when the project have its own website and a proper about and documentation section.

As far as contributing go, coding a bug fix or a new features takes way longer than figuring how sending patch over mail works (for the extreme case) and you only need to do it once.

And opensource is not a popularity contest.

"Discord servers and other contemporary solutions are much worse on the long run, but it does not matter. Software is like startups, long term is not a goal when you are not sure to survive (or in that case, being used and having contributors) next week."

I don't think I've read anything that I disagree with so strongly in a while. "Software is like startups" is about as user and contributor-hostile a concept as they come.

The long term absolutely matters and projects choosing convenience today over long-term thinking are screwing over their future. It's damn near impossible to find information about these projects outside the proprietary silos they've dug themselves into and they will regret the choice one of these days when Discord or whatever proprietary service starts tightening the screws to make money.

I'm not sure what you find hostile about their web appearance. It's a light, clean page with text that doesn't throw tons of JS at you, pop-ups, or a cookie accept/reject/ponder bullshit dialog. It could use a bit of a copy edit / redo and a screenshot (I always complain when a project doesn't have screenshots...), but I don't find it hostile in the least.