[RMPR]

Nice write-up.

> Screen offers a multi-user mode which allows to attach to Screen sessions owned by other users in the system (given the proper credentials). These multi-user features are only available when Screen is installed with the setuid-root bit set. This configuration of Screen results in highly increased attack surface, because of the complex Screen code that runs with root privileges in this case

I wasn't aware of such a feature but I guess it's what makes stuff like tmate possible. Speaking of which, I wonder if tmux is affected by the same kind of vulnerability.

[dooglius]

No, tmux uses unix domain sockets. I have no idea why screen chose to take the setuid approach instead here; it seems totally unnecessary to have root privileges.

EDIT: Further down, TFA gives a plausible explanation: the current screen devs are not fully familiar with the code base. If so, the setuid-root approach was probably the easiest way to make the feature work in lieu of such familiarity.

[JdeBP]

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/

[Henchman21]

I guessed something similar. Screen is from an era where setuid was pretty common!

[chasil]

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.

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

[gertrunde]

The original writeup by the OpenSUSE security team laid this out better:

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

Different distros built it in different ways, affecting level of vulnerability to the different issues.

[account42]

This "explanation" only makes it sound worse - why would you even consider setuid if you do not completely understand ever detail of the code base.

[fzzzy]

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

[icedchai]

I remember installing screen on a SunOS box back in the early 90's. It's been around a longggg time.

[fullstop]

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

[thanatos519]

It's a great feature! I have used it in training sessions by giving each student their own login on my laptop, with the ssh shell restricted to 'screen -x <specific user's window>' - the only window that user could use based on screen's ACLs. Then during exercises I (as the owner of the screen) could switch to each student's screen on the projector so the class could see what they had done.

Not surprised to hear it's full of security holes. :)

[cess11]

You can get close to the same experience with tmux.

https://superuser.com/questions/188501/is-there-a-way-to-hav...

Use groups instead of chmod 777.

[trollied]

Yup, screen -x

[qwertox]

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.

[trollied]

I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.

[radlad]

I was surprised to hear OP wasn't aware of it as it was the first reason I ever had to use screen (shared remote debugging session.)

[magicalhippo]

I use screen almost by default when connecting over SSH, but I've never used -x and didn't know about it.

Habbit from back in the dial-up days when connections got dropped quite frequently. Still relevant with laptop going into sleep mode and such.

So nice to just resume wherever you were as of nothing happened. Or to run jobs in the background, like long compiles, without an additional SSH session.

[esseph]

Often for long running jobs you want to see the status of where logging out of the system stops the job output.

[qwertox]

Or where you can't risk dropping the terminal session, like during a system upgrade via SSH.