10 ms·
Multiple security issues in GNU Screen
- RMPR 1y agoNice 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.
- trollied 1y agoYup, screen -x
- qwertox 1y agoThe 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 1y agoI am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
- radlad 1y agoI 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.)
- esseph 1y agoOften for long running jobs you want to see the status of where logging out of the system stops the job output.
- qwertox 1y agoOr where you can't risk dropping the terminal session, like during a system upgrade via SSH.
- esseph 1y agoSystem upgrade shouldn't drop your session btw, at least not on most flavors I'm familiar with
- ycombobreaker 1y agoThe 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,
- throwaway173738 1y agoA thoughtfully designed upgrade system doesn’t do the real work side your terminal session in the interactive process.
- ycombobreaker 1y agoDefense in depth is always valuable. The point of this thread is that screen protects your workflow from an unexpected disconnection.
- esseph 1y agoYou'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.
- dooglius 1y agoNo, 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 1y agoscreen 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/ https://sources.vsta.org/comp.sources.unix/volume10/screen/
- ngangaga 1y ago[flagged]
- 90s_dev 1y agoNostalgia and novelty are powerful narcotics.
- entropie 1y agoFor 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.
- noosphr 1y agoScreens 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.
- 1y ago
- thanatos519 1y agoIt'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 1y agoYou can get close to the same experience with tmux. https://superuser.com/questions/188501/is-there-a-way-to-have-shared-control-tmux-session https://superuser.com/questions/188501/is-there-a-way-to-hav... Use groups instead of chmod 777.
- deleted 1y ago[deleted]
- Trasmatta 1y agoOnly tangentially related, but I'm always fascinated that mailing lists are still a thing in 2025.
- teddyh 1y agoPlease, inform us of an alternative which is: • Non-proprietary • Federated • Archivable • Accessible • Not dependent on a specific company
- Trasmatta 1y agoI wasn't criticizing the use of them, I just find it fascinating that we still use them. They'll probably still be around in some form in another 3 decades.
- walterbell 1y agoEmail is a root-of-trust for authentication in most non-email systems.
- zoobab 1y agoGIT promised to be "Non-proprietary, Decentralized" but still does not have a built-in issue tracker :-)
- HappMacDonald 1y agoGIT is non-proprietary and decentralized so it keeps that promise. 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.
- somat 1y agoShouldn't the git native issue tracker be as simple as adding file pr/the_problem_i_am_having
- mmsc 1y agoIt's surprising that upstream was involved in this. Around 5 years ago, I came to the (sad) conclusion that GNU screen development had completely halted. Is that still not the case? Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?
- Trasmatta 1y ago> Due to difficulties in the communication with upstream we do not currently have detailed information about bugfixes and releases published on their end. 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.
- tecleandor 1y agoYep, from the timeline it looks like lack of communication (and maybe also capabilities/resources/time/will, not sure) [0] 0: https://security.opensuse.org/2025/05/12/screen-security-issues.html#8-timeline
- mmsc 1y agoSeems like a prime target for Jia Tan.
- croemer 1y agoInvolved only insofar as shipping it as setuid-root counts. Distros that configure it like this are vulnerable, others aren't. Very thin involvement I'd say. Distros patch if upstream is too slow.
- warpeggio 1y agoSo ... my tmux lifestyle is objectively superior in this one respect. Excellent.
- exploderate 1y agoYes, that's why all the cool kids switched to tmux 17 years ago. The only argument the screen camp had was "no serial port support in tmux". To which we answered something about a smaller more modern code base...
- kstrauser 1y agoI haven’t done serial port stuff in many years, so I ask this in ignorance and I give you permission to laugh at my naïveté. Can’t you just run tip or something in a tmux or zellij window and have basically the same thing?
- pengaru 1y ago> The only argument the screen camp had was "no serial port support in tmux". No, the screen camp has the valid argument that licenses matter and tmux is not GPL software.
- int_19h 1y agoFrom the end user perspective, it makes zero sense to avoid software just because it has an open source license that is more liberal than GPL.
- teddyh 1y agoNote: In Debian, GNU screen is not installed with setuid-root privileges.
- jesprenj 1y agoLikewise in Gentoo. But in Gentoo it has SETGID for utmp group. Though I'm not sure what the implications are.
- JdeBP 1y agoIf one is in group utmp, one can mess with the login accounting database: the table of currently active logins, the log of log-ons/log-offs, and the table of per-user last logins. https://jdebp.uk/FGA/unix-login-database.html 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/ 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.
- anthk 1y agoI set TMPDIR to $HOME/tmp because of that.
- 1y ago
- deleted 1y ago[deleted]
- worldsavior 1y agoRendered version: https://security.opensuse.org/2025/05/12/screen-security-issues.html https://security.opensuse.org/2025/05/12/screen-security-iss...
- jedimastert 1y agoHere's the rendered blog post: https://security.opensuse.org/2025/05/12/screen-security-issues.html https://security.opensuse.org/2025/05/12/screen-security-iss...
- mistrial9 1y agoso it appears that packaged Debian `screen` is not installed with root execution, therefore this entire situation is not a problem on Debian?
- TacticalCoder 1y ago[dead]
- zoobab 1y agoI emailed the author of GNU Screen about the lack of proper documentation about the logging to a file feature: http://www.zoobab.com/screenrc http://www.zoobab.com/screenrc GNU need a better issue tracking system :-)
- CelestialMystic 1y agoThere was a Q&A with the author of Tmux. He was complaining about the lack of documentation ~16 years ago. https://undeadly.org/cgi?action=article&sid=20090712190402 https://undeadly.org/cgi?action=article&sid=20090712190402
- anthk 1y agoTmux has been in OBSD base side several releases and documented since the first one.
- CelestialMystic 1y agoI know. I suggest you read the Q&A I posted.
- deleted 1y ago[deleted]
- amszmidt 1y agoIt is documented in detail in the GNU screen manual, https://www.gnu.org/software/screen/manual/screen.html#Log https://www.gnu.org/software/screen/manual/screen.html#Log
- Avamander 1y ago> 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.
- anthk 1y agoThen: 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.
- Scene_Cast2 1y agoI use byobu (for the keybinds) on top of tmux. But Zellij (modern Rust-based alternative to tmux) has been looking quite interesting for a while.
- phyzix5761 1y agoI brought up some security issues similar to these years ago to the Screen community and they laughed at me saying I was being paranoid. Nice to see they're finally doing something about it.
- seethishat 1y agotmux is in OpenBSD base since 4.6 IIRC and is/has been audited. It's a good alternative for those who want something a bit more secure.
- j45 1y agoSeeing screen popup reminded me of that one time I switched to tmux and forgot to use screen.
- sundarurfriend 1y agoZellij is a really nice, modern alternative to screen and tmux, and they've done a great job at having good defaults as well as making the UI easily discoverable. I'd highly recommend it to anyone else who felt dubious about the benefit-to-effort ratio of terminal multiplexers. https://zellij.dev https://zellij.dev https://github.com/zellij-org/zellij https://github.com/zellij-org/zellij
- collinvandyck76 1y agoI gave it a shot a couple years ago -- pretty slick. But the latency was noticeable compared to tmux, which I remain using today. I admit that I'm kind of sensitive to it, as at the time I was already on a latent connection.
- kstrauser 1y agoI personally haven't noticed that, but we all have different sensitivity levels to such things. Have you tried it more recently? A couple years ago is ancient in its lifespan. I'd be curious to see if it still feels sluggish to you. (Not a dev, just another end user.)
- collinvandyck76 1y agoNo, haven't tried recently, but will make a note to do so. Agree that a couple of years is an eternity :)
- kstrauser 1y agoRight on. I'd love to hear back about that. 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.
- afmrak 1y agoLast time I looked at Zellij it looked like a great new project in the multiplexer ecosystem, but didn't support a purely keyboard-driven copy/paste mechanism. I use that extensively and couldn't do without. So tmux it is until that gets added.
- lemonwaterlime 1y ago1. How many developers run all the most popular open source tools? 2. How much money is in the industries that use those tools?
- lowbloodsugar 1y agoIn 1990 we got told to stop using screen because other people could get into your sessions. Never used it again after that.
- nmz 1y agoIf you're worried about security, A less than 10k lines of SOC is your aim. mtm, abduco, dvtm achieve this. screen? Impossible for it to ever be secure. You'll be playing an endless game of whack-a-mole.
- lionkor 1y agolines of code is a measure of complexity in your argument; its better to call it that. Increased complexity, depending on the language, isn't necessarily lines of code, but can have the same effect
- themk 1y agoI do use abduco and dvtm, however, there is one major flaw in splitting the persistence and the emulator/multiplexer: if you detach, then reattach with a different terminal, with different capabilities, the emulator (which is running in abduco, say) doesn't know that it has to render differently. Compared to tmux, which knows this, and can adjust the rendering to suite the new terminal.
- nmz 1y agoIsn't this a bug of the software and not of the technology? 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.
- themk 1y agoMost terminal emulators have no way of reporting their capabilities at run time. And having dtach or abduco modify the TERM environment variable of the already spawned child is not possible, and even if it did, there is no standard way to get the child to reread it. 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.
- charcircuit 1y agoSetuid binaries existing in 2025 is not acceptable. There needs to a movement to remove all of them as time and time again it's shown that it leads to severe vulnerabilities.
- db48x 1y agoYou can run screen as setgid instead. Fedora sets up a system group called screen and installs screen as setgid so that the multiuser functionality works but cannot be accidentally used to do things as root.
- Pxtl 1y agoCan screen just get completely tossed and converted into a compatibility-layer wrapper around tmux?
- indigodaddy 1y agoAre there any official RedHat CVE pages for any of these screen vulns yet? Haven't found anything so far
- fistikcisahap 1y agoRedHat removed screen from the distro repos starting from RHEL8 and recommended tmux as the replacement. https://access.redhat.com/solutions/4136481 https://access.redhat.com/solutions/4136481
- indigodaddy 1y agoIt's still in EPEL I think but I guess that releases RH from having to address it?
- fistikcisahap 1y agoThat's right. EPEL is not an officially supported repo.
- kazinator 1y agoFunny you should mention screen and setuid. In one installation, I had to give screen chmod u+s perms to solve some weird issue, thinking what a gross thing to do. 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.)
- sweeter 1y agoNope, that's exactly how setuid works. You're setting the [s]pecial bit on a binary to tell the system to always run it as the provided [u]ser
- kazinator 1y agoNope, setuid programs have an effective UID as the owner (often root), but also have the real user ID of the original user. Programs intended for setuid operation pay attention to this; it is very important. They can use to to perform certain operations under privilege and then permanently drop to the original user.
- dminvs 1y ago> The observed behaviour has been present in Screen versions since at least the year 2005. 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
- 0xDEAFBEAD 1y agoWhat advantages does screen offer compared with multiple tabs in your terminal emulator?
- krferriter 1y agoI use it for running some multiple-hour jobs on a remote VM.
- magarnicle 1y agoThe terminal sessions will persist even if your emulator crashes. Or, if you ssh into a machine you can use multiple terminal sessions from a single connection, and you can disconnect and reconnect to those sessions later. 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.
- fergie 1y agoOne big one is the multi-user mode
- gitaarik 1y agoKeyboard shortcuts for searching and copying text from the scrollback buffer. Saving your sessions and tabs and restoring them after a reboot. A consistent experience regardless of which terminal emulator you use.
- curtisszmania 1y ago[dead]
- udev4096 1y agoEveryone I know has switched to tmux a long time ago. Screen is obsolete and shouldn't be used
- ho_schi 1y agoI love GNU Screen, daily usage. A good sign, that they called for help. Hope they can attract some more new developers, carefully maintaining it.