Multiple security issues in GNU Screen

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

Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?

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.

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

• Non-proprietary

• Federated

• Archivable

• Accessible

• Not dependent on a specific company

It sounds like they requested the security review, but have been difficult to keep in touch with? I'm not sure what the whole story is there.

It's rhetorical of course, it's because their users are completely blind to their pitfalls after decades of use, and it seems that generation-renewal is not a priority.

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.

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

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

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.

http://www.zoobab.com/screenrc

GNU need a better issue tracking system :-)

And having a built-in issue tracker

1. isn't related to those properties, and

2. isn't truly within the scope of a source code version control management solution.

That's the domain of project management.

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.

I would be happy to engage on that thought, but here on this thread there is a lynchmob gathering to declare an emergency to remove all GPL-connected code everywhere, again.. because `screen`

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.

Like any implementation, it comes with certain affordances which differ from other implementations.

Messages feel "heavy" for several reasons: sending one involves a lot of clicks (or keypresses); if you send a very high number you may be banned from your email provider, and unable to communicate with anyone.

Messages often arrive instantly, but can be delayed up to hours or days, so conversation round-trips are kept to a minimum.

Messages are all the same - there are no "lite messages" such as emoji reactions - so any message must contain enough content to justify being a full-fledged message, or it won't be sent at all. (Sometimes an "emoji reaction" is felt to be enough content to justify a full-fledged message, which is sent.)

Being off the web increases the barrier to entry, reducing the eternal september effect (ironically, Usenet is one of the least eternal-september-ish of the public discussion boards currently in existence).

Overall, the feel of the system tends to somewhat discourage quantity and encourage per-message quality.

lrwxrwxrwx 1 root root 12 Feb 11 2022 /usr/bin/screen -> screen-4.9.0

-rwxr-xr-x 1 root root 455016 Feb 1 2022 /usr/bin/screen-4.9.0

no suid

I used to hate that Debian always was behind on software versions, but now I use different package sources for the few applications where I really don't want to rely on old software (like browsers), and otherwise doing great with the old stuff :-)

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.

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.

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.

https://undeadly.org/cgi?action=article&sid=20090712190402

Unix: Small, light, mediocre OS for underpowered microcomputers. Either crash silently, or cut down the bloat.

MIT/GNU: Correct systems first. Plenty or resources. Lisp. Detect the errors, fix and step over them, continue the process.

Now:

GNU=Ugly bloated umUnix like, mega light Elisp editor but s l o w and prone to lock. Good FS' on Linux. FDo it's mainly Red Hat bloatware. Screen does too much.

OpenBSD=Correctness, ISC licensed mainly. Unix bound, small tools, but so-so FFSv2. Sndio works. Audio, video and so on perms work, no DBUS needed. CWM it's really fast and much easier than I3. Dumb config, fvwm looks like rocket science. Tmux, no screen(1) except for ports. Snappy, easy to config and script. Use damn cu(1) for serial, thanks.

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

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.

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

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

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.

https://git.savannah.gnu.org/cgit/screen.git/tree/src

A few 2kLOC files and the rest is rather small.

Personally I live by the maxim "if it can be separated without significant drawbacks, then it should be separate" but GNU tends to see it differently.

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

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

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

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.

What's wrong with debbugs? :)

https://zellij.dev https://github.com/zellij-org/zellij

No, the screen camp has the valid argument that licenses matter and tmux is not GPL software.

2. How much money is in the industries that use those tools?

I would love to switch to a modern, maintained terminal multiplexer, but it would need to, well, be good at multiplexing.

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.

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

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.

Haven't you heard about the abomination which is Office365? They recently bolted emoji reactions onto email!

  apt-get changelog firefox
  Get:1 store: firefox 138.0.3~build1 Changelog
  Fetched 129 B in 0s (0 B/s)
  firefox (138.0.3~build1) UNRELEASED; urgency=medium
 
    * N/A
 
   -- Mozilla <release@mozilla.com>  Mon, 12 May 2025 12:40:33 -0000

  date
  Tue May 13 08:56:09 AM PDT 2025

  apt-get install --download-only --reinstall firefox

USB is a serial BUS, which allows multiple devices; serial ports are single device (if my memory serves).

https://qa.debian.org/popcon.php?package=screen

I note that tmux has only 40K users (of debian popcon users)

https://qa.debian.org/popcon.php?package=tmux

I am considering to try the link shared previously:

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

Now I miss a way to translate CLI options and batch files

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

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.

If you want a rethinking of the idea: zellij.

I prefer the latter. It matches my mental model of such things, and lots of people talk about enjoying switching to it. Many others happily use the former daily.

Ubuntu it's not set.

(Not a dev, just another end user.)

I've seen how that mindset has ruined several companies. Not saying that you're wrong about that particular program that is, after all, free software replaced by other free software parts. But for business, it's lethal.

Joel Spolsky had a nice piece about it:

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

That and Fire and Motion seem to be forgotten wisdom already:

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

I feel old :-)

I've had some luck with mosh, but that also seems kind of moribund.

https://mosh.org

For my use case it's fine.

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

Tbf, they are probably all dead now anyway.

Also, how come open source names can even be bought? They should be open, of course, so I think it'd be fair enough if they wanted to call theirs "MuseScore Audacity" or something like that.

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.

Originally, you communicated with the computer using a teletype or video terminal connected to a serial port. Whatever you typed went to the computer, and whatever the computer sent back was printed on your terminal screen (or paper in the case of a teletype).

The UNIX (and thus, Linux) command line environment still works this way, except the serial line is virtual.

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.

- can only participate in conversations via e-mails

- unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox

- NOT accessible, especially in the disabilities sense

- doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability

- no responsive design, tiny text and horizontal scrolling on mobile phone screens

- sends you your password in cleartext via e-mail

- actually complicated to unsubscribe from a list / manage your membership

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.

It could also be in my case that I use it so little that some latency is tolerable. I don't develop interactively in zellij or tmux. I mainly keep some logs tailing, and DB consoles open, etc, and I don't check them super often.

I switched to tmux eventually though.

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.

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.

Turns out, it has features dependent on setuid, and some systems ship it that way? Yikes!

(But, after I gave u+s to screen, it reads root's ~/.screenrc instead of mine (which I accepted as part of the workaround). Maybe that particular build of screen I'm using doesn't react properly to setuid; maybe it has to be built a certain way also to enable that support.)

https://access.redhat.com/solutions/4136481

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.

GP's point is that convenience and long-term thinking don't have to be an either-or. We should have convenient tools that don't require proprietary silos but work well on today's devices and with today's use cases.

The web has horrible usability if you use a text-based browser. I.e. if you use a mail reader with good usability, a mailing list has good usability. This is a client-side issue, not a technology issue.

> - can only participate in conversations via e-mails

Um, yes, a mailing list uses e-mail. I don’t know what you expected.

> - unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox

If you are a new user, and want to reply to a mail you read in the list archive, just write a new mail; there is no strict rule that any discussions must be restricted to one thread.

Indeed, if you want to start a new discussion after some time has elapsed, a new thread may be preferred.

> - NOT accessible, especially in the disabilities sense

Again, this is a client issue. I believe that e-mail is actually the preferred form for those with accessibility needs.

> - doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability

Somewhat true, but this depends on the list – some list archives do feature search – and is very rarely a problem in practice, since external search engines are very efficient.

> - no responsive design, tiny text and horizontal scrolling on mobile phone screens

Again, a client issue. Get a better e-mail client.

> - sends you your password in cleartext via e-mail

Yes, many lists do this, but this is not a requirement of the technology. Some lists could require all your mails to be signed with PGP or S/MIME; it is entirely up to the list.

> - actually complicated to unsubscribe from a list / manage your membership

Not really. The ”List-Unsubscribe” header is commonly sent in every mail to the list.

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

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.

and it's been an anti-pattern and covered by tools like rkhunter for around least that long, as well

but pretty sure screen was setuid root in the 90s too

It's simply a release from Mozilla's Extended Support Release channel, as distinct from the Rapid Release channel that you are apparently using. Not a different project/product.

https://support.mozilla.org/en-US/kb/choosing-firefox-update...

To be clear, that's what I was imagining. If you had a shell script that called screen, it would now work via tmux, but no one would be "tricked".

And for serial ports

This update fixes security issues:

* attacher.c - prevent temporary 0666 mode on PTYs.

* avoid file existence test information leaks.

* socket.c - don't send signals with root privileges.

I guess, but does it really get in the way?

I use tmux only for scrollback and having multiple "tabs" and sessions, and not much else. But the more advanced stuff like splits and whatnot never really get in my way.

If I wanted to use IRC, I’d use IRC.

There's a few other features like a common clipboard of sorts, monitoring a session for silence/activity, but those could all be provided by your emulator.

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

Use groups instead of chmod 777.

A good sign, that they called for help. Hope they can attract some more new developers, carefully maintaining 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.

Missed it? Not at all, Debian pioneered that style of bugs years before!

https://github.com/g0tmi1k/debian-ssh

This is a problem with quite a few older projects, that issues get buried in the endless depths of unindexed mailing lists, if at all. People bemoan Discord (rightfully) for making info like this unaccessible, but IRC (that some projects still use) is basically twice as bad.

I really wish these projects would migrate to Gitea/Forgejo/Codeberg, GitLab or GitHub or anything like that, just to bring these things together and provide vital discoverability.

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.

But also, part of the problem is the use of email lists. Or rather, specifically, plain text emails, because they contain pre-wrapped lines, and users often assume monospace font. You can try to reflow, but in general it's not possible to determine whether any given line break is there because the line just needed to be wrapped, or because it's actually meaningful (for code, diagram etc).

Compared to tmux, which knows this, and can adjust the rendering to suite the new terminal.

refetching terminfo capabilities seems an easy fix, you also get sigwinched which I imagine happens on a new terminal.

Mind you, I don't use abduco but do use dtach sometimes, I've accepted that I need screen and tmux with all its warts, like instead of using a scripting language like TCL/Lua for configuration it built its own frankenstein language that is severely limited.

If we're talking about someone who has received a binary copy of software, then isn't this obvious?

The MIT license permits the distributor to close the source of what they've redistributed, in original or modified form. Potentially depriving the end user of the freedom to view/modify/distribute the source.

Permissive licenses prioritize rights of the software redistributors at the expense of the end users.

https://en.wikipedia.org/wiki/Copyleft#Freedom

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)

Edit: and to your point of a distributor withholding the source: yeah, so? If there ever came a point where the current maintainer closed its source (unlikely), somebody with a copy of it can step in with a fork. Or the project can die a deserved death for closing its source. At this point the benefits of open source are pretty much obvious to anyone with a brain, and closing the source of an open-source project is practically suicide.

In screen & tmux you can also use vim shortcuts to navigate the scrollback buffer. That is so convenient and makes me work so fast. I can search for a snippet close to where I want to copy some text, and then navigate more precisely with the vim shortcuts.

So that's the first thing I look for in a terminal multiplexer, because if you're gonna expect that I'm gonna put my right hand off the keyboard and use the MOUSE to awkwardly select some text in a TERMINAL, then you expected wrong.

If you're interested I can share my config.

Saving your sessions and tabs and restoring them after a reboot.

A consistent experience regardless of which terminal emulator you use.

You can just use one session if you like, and if you do, it's the default, so you don't have to do anything special.

Tabs and Windows work similar as in screen as far as I can see.

EG https://en.m.wikipedia.org/wiki/VT220

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.

So, no, the tech is kinda broken. The only correct thing to do is to have the attaching program also do terminal emulation (or, assume that you always attach with a compatible terminal).

You could make it a simpler form of emulation, and then have the more complex muxing ability as a separate program, at the cost of having to go through multiple emulation layers.