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.

Yup, screen -x

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/

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.

Nostalgia and novelty are powerful narcotics.

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

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

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

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.

On my sistems screen doesn't have setuid.

I switched to dtach for the first case.

It's a combination of factors:

* The original author of the project has not been involved in it since 1990. The people who took it over and made it a GNU project then largely stopped working on it in 2004. The people who are now working on it are something like its 3rd or 4th wave of developers.

* Learning the internals of screen now from scratch is a lot harder than when I did it in 1987. There's an awful lot more operating system historical and portability factors, now. In 1987, it was works-on-4.3BSD-might-not-on-your-Unix.

* If you deal with pseudo-terminals cross-platform, there are still huge variations on how pseudo-terminals work and how the long-standing security issues of pseudo-terminals, identified in the 1990s, have been addressed in operating systems.

* screen is encumbered by a lot of 1980s Think. It still today diligently manages, and puts quite a lot of effort into constructing, a generated-on-the-fly TERMCAP environment variable, for example.

* Attitudes to security have changed. At least one security hole in the headlined report was actually a neat-o feature of terminals in Unix in the 1970s and 1980s.

Emacs can work as a daemon.

Try as I might I cannot get my fingers to re-learn the tmux keybindings. The GNU Screen keybindings are that burned into my brain.

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.

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

SvP https://github.com/grml/grml-etc-core/blob/master/etc/tmux.c...

dtach for session persistence. “Do one thing well.”

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

Not an emacs user, but for this, what does screen do that tmux can't?

Port something like this to OpenBSD and then say that this sort of thing is not hard work. (-:

It's very hard work, especially nowadays. The sweet spot was probably in the 1990s, when novices were still likely to know that prime sources of knowledge about this stuff were posts on Usenet, or shell archives of text files written by Daniel J. Bernstein.

https://jdebp.uk/FGA/bernstein-on-ttys/

I speak from experience of being someone who did my own tweaks to screen in the 1980s, and who has written other similar programs from scratch.

I'm confused by this statement. Are you claiming this is the projects' stated goal? Their primary use in the wild?

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

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

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.

A similar process is happening with zellij and tmux. Since I switched over I feel that tmux is obsolete.

What does it do better than tmux?

Or is it more of a fish vs. zsh type of situation, where neither is obsolete, but the target audience is just very different?

What's your point besides whining about the general state of "delevopers", whoever that is? Are you volunteering to take over maintenance of GNU Screen?

Really, the gall to complain about "laziness" when all you're doing is spreading negativity on a forum.

A quick example is that mouse scrolling works by default. I see it more like ripgrep vs grep. Either can do almost anything the other can, but one has much more modern, ergonomic defaults.

Nah, screen's main use case is as an ad-hoc method to daemonise random scripts.

Nothing at all. I’ve used emacs over tmux (and now zellij) for many years. Emacsserver can replace both of them, but that’s a different story.

It really is magical, isn’t it? And although I rarely need to use it, I love the multihop setups where you can ssh to this system, then ssh again to this other, then mount an SMB filesystem using these credentials, and start editing.

Thankfully you can configure it. I had the same initial difficulty.

Same here (speaking more specifically about debian)

Definitely more of a fish vs zsh situation, in my opinion.

tmux, to me, feels like "modern screen". It has some cool features, but at the end of the day, it just wants to be a terminal multiplexer. Great!

Zellij on the other hand seems to offer terminal multiplexing as an obvious first-class use case but "not the whole point". At the surface, Zellij is an opinionated terminal multiplexer that uses a nice TUI to give discoverability which you can turn off when you're ready to gain screen real estate. It's easy to make Zellij behave exactly like tmux/screen, and it's easy to configure via a single config file.

Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things. For instance I once built[0] a python cli app which had a command that would launch a zellij workspace with various tabs plugged in to other entrypoints of that same python cli, basically allowing me to develop a multi-pane TUI as a single python Typer app. In one pane I had the main ui, and then in another stacked pane I had some diagnostic info as well as a chat session with an llm that can do tool-calling back out to the python cli again to update the session's state.

I think wrapping up a project's dev environment as a combination of mise (mise.jdx.dev) and zellij or nix+zellij to quickly onboard devs to, say, a containerized development environment, seems like a really neat idea.

0: https://github.com/eblume/mole/blob/main/src/mole/zonein.py -- but this is mostly derelict code now, I've moved on and don't use zellij much currently.

[flagged]

I hadn't used Zellij before, but I tried it out. Visually it works better than tmux and it shares enough key bindings with tmux to make it a pretty seamless transition.

With that being said, the binary is huge. I get that zellij is statically linked, but tmux is about 900KiB and has minimal dependencies. I'm flabbergasted that a terminal multiplexer, stripped, is 38MiB.

Terminals are obsoleted by Arcan:

https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...

We usually wait for a version written in Rust for this kind of cruft removal.

Engineers are rational people. Software developers calling themselves "engineers" are not.

The problems here are more about the architecture. You can write 100% memory-safe but completely insecure code in Rust, Java. Haskell, Erlang, Smalltalk, bash, you name it. For instance, running a setuid binary may add problems to code written in any language.

Yeah this is 100% of when I reach for screen. “I’m not willing/ready to make this a service, screen detach here I come”

Looking at the source code I assume it's just the amount of cargo deps. Some of which I'm not sure what place they have on a tmux at a first glance.

I used to used zsh, like I still have have karma moving up on stackoverflow as I answered my own questions on some obscure configuration fine tuning. But currently I'm more in a "give me the thing that work off the shelf" moment, so I take fish and don't plan to either look back.

Byobu with tmux as backend is my go to solution if I want a multiplexer, for what it worths.

True, but zellij also does more. I'd also give it more of a stink eye if it were something I were running many times inside the inner loop of a script, but as something you generally launch once and leave running forever, eh.

I occasionally have to recalibrate my units. I just launched Emacs on my Mac and it's using 350MB of RAM. That's astonishing when I think about Amiga programs I wrote, but it's also just 0.53% of the RAM in this particularly machine. It's probably larger than it could be if someone ruthlessly trimmed it back, but I'd rather spend that time using the other 99.4% of my machine to do more fun stuff.

From a quick read, all I can see is a manifesto for emacs.

Is it actually in common usage? I'm sure it's used by a lot of people, but it seems quite niche still.

On my gentoo box it's setgid hmmm.

Ubuntu it's not set.

How though? Genuine question; x11 didn't obsolete terminals. Does Arcan do something X11 couldn't?

Cheers, that's interesting. There are a few instances of ([]) which look like broken links in:

https://jdebp.uk/FGA/bernstein-on-ttys/cttys.html

Tbf, they are probably all dead now anyway.

That’s great for your own machine or even common home directory scenarios. The issue is when you have a bunch of machines to manage without chef/puppet/etc or hop onto a random machine or a machine you don’t own etc… defaults are what you get to work with.

If screen is there and I need to do something that lasts longer than my ssh session, screen is what I reach for. If it’s non-interactive, I reach for nohup next.

I have a few embedded devices which have just 128MiB of flash, and they can run tmux just fine. I wouldn't even consider zellij for this purpose, of course, and having tmux down there is more of a "this is a nice thing for development purposes" thing.

Regarding memory usage, Zellij appears to take up 63 MiB versus tmux's 3.8MiB. It's nice and all, but quite a pig. This is on Linux, maybe Mac is different.

Among a certain subset of linux users, new is always better.

Hopefully some effort is eventually put into slimming things down.

Embedded is a lot different, to be sure. I'm surprised there's room for tmux on something that tiny.

But on desktop systems, on my Mac, Zellij takes 28MB of disk and 40MB of RAM. That's 1/37,000th of my available disk and 1/1,600th of my RAM. I'm all for optimized, tiny apps, but those are below my attention threshold.

True, it's not really as if it's a massive codebase

It's used a lot for legacy reasons I think. People didn't move to something newer like tmux because why would they? It's super handy to keep stuff running on a console while disconnected from it. In that sense it (or at least, tools like it) are indispensable.

Nothing but replacing it with something newer invalidates decades of muscle memory.

I switched to tmux eventually though.

If I recall correctly (I transcribed that years ago.) they were lost in the original. They wouldn't have been links. It was written in 1991.

> Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things.

That’s been a pretty standard feature of tmux since forever.

In fact the reason I first discovered tmux was because some Irssi (terminal IRC client) plugins used tmux to create additional panes for Irssi.

tmux is one of those tools that does a lot more than most people realise but the learning curve is steep and features aren’t easy to discover.

Zellij looks interesting but these days I mostly use tmux as a control plane rather than a terminal UI. So the enhancements of Zellij are wasted on me.

> Try as I might I cannot get my fingers to re-learn the tmux keybindings. The GNU Screen keybindings are that burned into my brain.

This. I have tried switching away from screen a few times. But failed because the keybindings are burned into my brain as well.

I will try harder.

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

Note that "embedded" like this includes e.g. many modern routers.

Also note that computers with much less disk space than 128 Mb could and did run full-fledged GUI apps in the past. For example, the entirety of Windows 95 is ~100 Mb when installed.

The product uses libevent and libc already, so adding tmux only consumes a few hundred KiB in the image. The root filesystem is squashfs, so it's even less in practice.

Let's see, we have at least daemonize[0], nohup[1], and disown[2] for that. Some discussion of the differences: https://unix.stackexchange.com/questions/3886/difference-bet...

[0] https://github.com/bmc/daemonize

[1] https://linux.die.net/man/1/nohup

[2] https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash....

If the keys and functionality don't work exactly as GNU Screen does then this won't help me. The behavior and keystrokes are so far burned into my brain that it doesn't make sense at this point to learn a new tool unless/until every system I use under the sun doesn't support GNU Screen anymore.

I’m not sure what the screen keybindings are anymore but you could always rebind the tmux key so.

> I'm surprised there's room for tmux on something that tiny.

A question that comes to mind is, under what circumstances would you expect a TUI based program that processes streaming text not to fit on a system that is otherwise capable of user interaction? It seems vaguely in the vicinity of the simplest possible interactive task you could come up with.

Certainly it generally isn't worth hyper-optimizing mainstream desktop applications to wring out the last few MB, let alone KB, of RAM in this day and age. However that doesn't answer the question - why would more than 1 MB of program binary be required for multiplexing text in a terminal? At least at first glance it honestly seems a bit outlandish.

IDK Man the hammer I use today looks a hell of a lot like the hammer used by engineers throughout human history.

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

Screen is useful when you need to a nest multiplexing inside tmux.

And for serial ports

Sysadmin types, often daily

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

If you don’t care about the output or handle it manually, use detail over nohup, it’s a bit nicer.

They re-keyed it specifically so it could be nested, however, they mention the prefix key is intentionally dumb and ment to be remapped, probably to ^a like screen.

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

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.

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.

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.

System upgrade shouldn't drop your session btw, at least not on most flavors I'm familiar with

The risk is anything else dropping your connection while an interactive long-running process is going. You can nohup, or run inside something like screen/tmux,

A thoughtfully designed upgrade system doesn’t do the real work side your terminal session in the interactive process.

A more modern alternative is systemd-run: <https://www.freedesktop.org/software/systemd/man/latest/syst...>

Defense in depth is always valuable. The point of this thread is that screen protects your workflow from an unexpected disconnection.

^a is the worst for emacs users since ^a is begging-of-line which we use a ton.

When I first started using screen some years ago the emacswiki (I think) even mentioned it and recommended to remap it to ^p which it is for me for screen and tmux since then.

(I could remember something wrong here)

I've just worked '^a a' into my terminal emacs muscle memory.

You're not wrong, but largely in the virtualized world we live in, it matters less and less when you have a virtual console.

That said the sshd session you are connected on is still running the old executable until the service is restarted AND your session ends, so even if sshd gets upgraded, you should still be good to go.