Multiple security issues in GNU Screen

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.

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.

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/

For me it felt (!) like screen is pretty much obsolute since 10+ years. When tmux came I switched and never looked back and I know a few that handled it the same.

Screens main use case is to open an emacs session remotely.

Tmux's main use case is to be glue for a unix IDE.

The two use cases are rather different and the tools are very specialized for them.

Emacs can work as a daemon.

It also has tramp mode which means you can use all your local packages remotely.

When I realized how powerful TRAMP was, I don't think I ever used screen/tmux again. I'm sure there are uses, mind. Just TRAMP fully hit all of my needs.