Multiple security issues in GNU Screen
openwall.com
openwall.com
> 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.
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.
$ 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.
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.
Not surprised to hear it's full of security holes. :)
https://superuser.com/questions/188501/is-there-a-way-to-hav...
Use groups instead of chmod 777.
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.
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.
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 :-)
Missed it? Not at all, Debian pioneered that style of bugs years before!
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.
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 firefoxIt'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...
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
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.
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.
https://security.opensuse.org/2025/05/12/screen-security-iss...
http://www.zoobab.com/screenrc
GNU need a better issue tracking system :-)
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.
(Not a dev, just another end user.)
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.
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.
Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?
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.
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 :-)
https://git.savannah.gnu.org/cgit/screen.git/tree/src
A few 2kLOC files and the rest is rather small.
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.
I've had some luck with mosh, but that also seems kind of moribund.
For my use case it's fine.
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.
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.
0: https://security.opensuse.org/2025/05/12/screen-security-issues.html#8-timelineThough 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.
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.
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.
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".
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.
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.
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
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
2. How much money is in the industries that use those tools?
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.)
No, the screen camp has the valid argument that licenses matter and tmux is not GPL software.
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.
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.
I would love to switch to a modern, maintained terminal multiplexer, but it would need to, well, be good at multiplexing.
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.
A good sign, that they called for help. Hope they can attract some more new developers, carefully maintaining it.
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.
Saving your sessions and tabs and restoring them after a reboot.
A consistent experience regardless of which terminal emulator you use.
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.
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.
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.
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.
Haven't you heard about the abomination which is Office365? They recently bolted emoji reactions onto email!
• Non-proprietary
• Federated
• Archivable
• Accessible
• Not dependent on a specific company
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.
What's wrong with debbugs? :)
- 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
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.
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.
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.
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.
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.
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).
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`
If I wanted to use IRC, I’d use IRC.