[HN Gopher] Multiple security issues in GNU Screen
___________________________________________________________________
Multiple security issues in GNU Screen
Author : st_goliath
Score : 323 points
Date : 2025-05-13 11:28 UTC (11 hours ago)
(HTM) web link (www.openwall.com)
(TXT) w3m dump (www.openwall.com)
| RMPR wrote:
| 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.
| trollied wrote:
| Yup, screen -x
| qwertox wrote:
| 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.
| trollied wrote:
| I am well aware of setuid. I was informing the parent
| comment of which arg to use for the actual functionality.
| johnmaguire wrote:
| 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.)
| dooglius wrote:
| 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.
| JdeBP wrote:
| 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/
| ngangaga wrote:
| Kind of nuts that a tool that hasn't fixed nearly 40-year
| old practices is in common usage among developers. Never
| tell me engineers are rational people.
| 90s_dev wrote:
| Nostalgia and novelty are powerful narcotics.
| entropie wrote:
| 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.
| noosphr wrote:
| 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.
| skydhash wrote:
| I switched to dtach for the first case.
| kps wrote:
| dtach for session persistence. "Do one thing well."
| anthk wrote:
| Emacs can work as a daemon.
| noosphr wrote:
| It also has tramp mode which means you can use all your
| local packages remotely.
| taeric wrote:
| 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.
| kstrauser wrote:
| 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.
| penguin_booze wrote:
| > 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?
| kstrauser wrote:
| 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.
| wkat4242 wrote:
| Nothing but replacing it with something newer invalidates
| decades of muscle memory.
|
| I switched to tmux eventually though.
| johnmaguire wrote:
| I'm confused by this statement. Are you claiming this is
| the projects' stated goal? Their primary use in the wild?
| jstanley wrote:
| Nah, screen's main use case is as an ad-hoc method to
| daemonise random scripts.
| fnordpiglet wrote:
| 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"
| senderista wrote:
| 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....
| DrillShopper wrote:
| 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.
| SSLy wrote:
| SvP https://github.com/grml/grml-etc-
| core/blob/master/etc/tmux.c...
| DrillShopper wrote:
| 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.
| Cerium wrote:
| Thankfully you can configure it. I had the same initial
| difficulty.
| imoverclocked wrote:
| 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.
| cheema33 wrote:
| > 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.
| hsbauauvhabzb wrote:
| I'm not sure what the screen keybindings are anymore but
| you could always rebind the tmux key so.
| dbdoskey wrote:
| A similar process is happening with zellij and tmux.
| Since I switched over I feel that tmux is obsolete.
| lxgr wrote:
| 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?
| kstrauser wrote:
| 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.
| eblume wrote:
| 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/zone
| in.py -- but this is mostly derelict code now, I've moved
| on and don't use zellij much currently.
| hnlmorg wrote:
| > 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.
| psychoslave wrote:
| 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.
| thesuitonym wrote:
| Among a certain subset of linux users, new is always
| better.
| fullstop wrote:
| 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.
| spookie wrote:
| 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.
| fullstop wrote:
| Hopefully some effort is eventually put into slimming
| things down.
| kstrauser wrote:
| 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.
| fullstop wrote:
| 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.
| kstrauser wrote:
| 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.
| int_19h wrote:
| 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.
| fullstop wrote:
| 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.
| fc417fc802 wrote:
| > 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.
| pabs3 wrote:
| Terminals are obsoleted by Arcan:
|
| https://arcan-fe.com/2025/01/27/sunsetting-cursed-
| terminal-e...
| skydhash wrote:
| From a quick read, all I can see is a manifesto for
| emacs.
| procaryote wrote:
| How though? Genuine question; x11 didn't obsolete
| terminals. Does Arcan do something X11 couldn't?
| guappa wrote:
| On my sistems screen doesn't have setuid.
| rixed wrote:
| Same here (speaking more specifically about debian)
| bombcar wrote:
| On my gentoo box it's _setgid_ hmmm.
|
| Ubuntu it's not set.
| JdeBP wrote:
| 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.
| bulatb wrote:
| Prideful people who've defined themselves as being good,
| and arbitrarily decided being rational is good, conclude
| that since they're good, and rational is good, they must
| be rational.
| UI_at_80x24 wrote:
| We usually wait for a version written in Rust for this
| kind of cruft removal.
| nine_k wrote:
| 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.
| 1vuio0pswjnm7 wrote:
| Engineers are rational people. Software developers
| calling themselves "engineers" are not.
| mardifoufs wrote:
| Is it actually in common usage? I'm sure it's used by a
| lot of people, but it seems quite niche still.
| wkat4242 wrote:
| 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.
| wkat4242 wrote:
| True, it's not really as if it's a massive codebase
| fullstop wrote:
| I guess I'm glad that I switched to tmux ages ago.
| fzzzy wrote:
| screen has used setuid root for multiuser for at least 20
| years. Used to use it in multiuser for remote pair
| programming.
| icedchai wrote:
| I remember installing screen on a SunOS box back in the
| early 90's. It's been around a longggg time.
| chasil wrote:
| 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.
| thanatos519 wrote:
| 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. :)
| Trasmatta wrote:
| Only tangentially related, but I'm always fascinated that mailing
| lists are still a thing in 2025.
| teddyh wrote:
| Please, inform us of an alternative which is:
|
| * Non-proprietary
|
| * Federated
|
| * Archivable
|
| * Accessible
|
| * Not dependent on a specific company
| Trasmatta wrote:
| I 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 wrote:
| Email is a root-of-trust for authentication in most non-
| email systems.
| zoobab wrote:
| GIT promised to be "Non-proprietary, Decentralized" but still
| does not have a built-in issue tracker :-)
| HappMacDonald wrote:
| GIT _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 wrote:
| Shouldn't the git native issue tracker be as simple as
| adding file pr/the_problem_i_am_having
| badmintonbaseba wrote:
| Issues shouldn't really live in the same source tree,
| IMO. But AFAIK there are forges that keep the issues in
| the same repository, just not in the same tree of commits
| that the source tree has, git notes style.
| rixed wrote:
| Any user without commit permission should be able to
| create tickets and comment on them.
|
| What's wrong with debbugs? :)
| delfinom wrote:
| For large projects like the Linux kernel as an example out
| of many, I would assume the built-in issue tracker would
| end up 100x the size of the code base in storage space. lol
| graemep wrote:
| Fossil has one. If its something you want use Fossil -
| which I think is a great alternative for small teams, on
| the other hand, this is probably not something large teams
| (which are a high priority for git) want.
| jbaber wrote:
| If I ever get around to writing my git issue tracker,
| everything will be stored in a completely separate
| reponame-issues.git
| Eduard wrote:
| - horrible usability
|
| - 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
| teddyh wrote:
| > _- horrible usability_
|
| 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.
| KolmogorovComp wrote:
| My qualm against them is rather different. Why, after so much
| time, are they still so user-hostile, both in their web
| appearance and more generally usage?
|
| 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.
| skydhash wrote:
| I don't think GitHub adds that much over using and
| contributing to software. I generally prefer when the project
| have its own website and a proper about and documentation
| section.
|
| 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.
| jzb wrote:
| "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."
|
| 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.
| mistrial9 wrote:
| > The long term absolutely matters and projects choosing
| convenience today
|
| 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`
| int_19h wrote:
| Try opening that link on a phone. You get tiny, hard-to-
| read text because of course it's monospace with hardcoded
| line breaks.
|
| 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.
| SoftTalker wrote:
| Yes, ideally for a web archive the text should be flowed
| and styling responsive. That's a flaw of the web site not
| the use of email lists.
| SoftTalker wrote:
| I've never used a discord server and would not know how. If
| that's the communication channel you choose, I'm out.
| immibis wrote:
| A mailing list is just a kind of public group chat. You're
| probably in many public group chats, including this one right
| now. Mailing lists, IRC, traditional web forums, Discord,
| WhatsApp are all implementations of the same basic concept.
|
| 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.
| WesolyKubeczek wrote:
| > 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.)
|
| Haven't you heard about the abomination which is Office365?
| They recently bolted emoji reactions onto email!
| mmsc wrote:
| It'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 wrote:
| > 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 wrote:
| Yep, 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 wrote:
| Seems like a prime target for Jia Tan.
| croemer wrote:
| Involved 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.
| mmsc wrote:
| TFA says upstream asked for the review.
| croemer wrote:
| Right, I got the direction wrong.
| Eduard wrote:
| "TFA"?
| shawn_w wrote:
| The Fine Article
| jzb wrote:
| Upstream _requested_ that the SUSE team take a look at it. It
| seems that development is understaffed and the upstream may not
| have the expertise to maintain it properly. Which, if true, is
| sad -- I know that tmux and others exist, but a lot of people
| have used Screen for many many years. It sucks when a tool
| bitrots.
| marcosdumay wrote:
| Looks like a tech-debt ridden large piece of software that
| new developers just can't understand.
|
| 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.
| megous wrote:
| It's not large:
|
| https://git.savannah.gnu.org/cgit/screen.git/tree/src
|
| A few 2kLOC files and the rest is rather small.
| doctoboggan wrote:
| What are the replacement tools I should be looking at as a
| casual user of screen?
| nosrepa wrote:
| Tmux
| kstrauser wrote:
| If you want screen-but-better: tmux.
|
| 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.
| bombcar wrote:
| tmux is great but it's way too powerful for the 90% use
| case of screen - which is "let this process continue to
| run even if I disconnect or logout".
|
| I've had some luck with mosh, but that also seems kind of
| moribund.
|
| https://mosh.org
|
| For my use case it's fine.
| kstrauser wrote:
| Along the lines of Mosh, I've migrated from it to Eternal
| Terminal (ET): https://eternalterminal.dev
| int_19h wrote:
| If that is literally the only thing that you need, dtach
| is the ticket.
| narag wrote:
| _Instead, it 's doomed to rot until it's replaced of
| rewritten._
|
| 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 :-)
| immibis wrote:
| Open source does have a problem with inertia whenever one piece
| of software ends and another piece is created to replace it,
| but there's no immediate incentive to switch, because it is a
| switch, not an update.
|
| 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.
| Wowfunhappy wrote:
| Isn't this what distros are for? So e.g. Debian could decide
| to replace screen with tmux, possibly with some sort of
| compatibility package that takes all the same command line
| arguments as screen but uses tmux under the hood. (I've used
| screen very little and have never used tmux so I'm not sure
| if that would make sense in this context).
| kevin_thibedeau wrote:
| Tmux doesn't support serial ports.
| PhilipRoman wrote:
| I'm not sure what made "screen" integrate the two
| separate pieces of functionality - you can use something
| minimal like "tio" for serial port access and it's much
| more elegant.
| kevin_thibedeau wrote:
| It isn't separate functionality. Terminals connected via
| serial port is a valid use case for a _terminal_
| multiplexor.
| PhilipRoman wrote:
| In theory you're correct, but by that logic you'd also
| have to add ssh (probably by far the most common way of
| connecting to a remote terminal today). I guess you'd end
| up with something like mobaXTerm which is a valid
| approach for sure, but doesn't compose as well.
|
| 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.
| JdeBP wrote:
| It's not separate functionality. The back end (so-called
| "master" side) of a pseudo-terminal is almost (bar
| initialization of line speed, hardware flow control, and
| framing settings) indistinguishable from a "null-modem"
| call-out serial port or parallel port terminal device.
| Write a software terminal emulation program for the
| former, which of course is what screen has, and you
| already have one for the latter.
| nottorp wrote:
| I'm sure a rewrite of screen in Rust will be 105% secure.
| And won't support serial ports either.
| im3w1l wrote:
| What is a serial port and what do you use it for?
| genewitch wrote:
| It is a port that has two data lines, RX and TX, and data
| is sent in a serial fashion across those data lines. It
| is used today for embedded systems, routers and switches
| et al, and getting a console on any machine that doesn't
| have a gpu with a monitor attached.
|
| USB is a serial BUS, which allows multiple devices;
| serial ports are single device (if my memory serves).
| spauldo wrote:
| When most people use the term "serial port" they're
| referring to a DB-25 or DE-9 port you find on older
| computers or USB dongles. It's also seen in 8P8C (aka
| "RJ45") form sometimes, especially in industrial
| equipment. It can send and receive "characters" (anywhere
| from 5-8 bits each) one at a time at a fixed rate, either
| half duplex or full duplex. They usually implement one or
| more of the RS232, RS422, or RS485 standards.
|
| 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.
| marcosdumay wrote:
| You can reconfigure the key-bindings, that I guess would be
| the largest annoyance for a new user. But there are many
| fundamental differences between them that you just can't
| hide.
| rzr wrote:
| A smooth transition from GNU screen to tmux, will be
| appreciated for potentially 60K users.
|
| 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
| layer8 wrote:
| You generally can't transparently replace a tool by a
| different one like that, siblings are giving examples of
| where there would be incompatibilities. There would also be
| much upheaval among users if a distribution would try to
| underhandedly perform such a replacement. If anything, a
| package "tmux-as-screen" could be provided for those who
| want that.
| 3036e4 wrote:
| The good solution is rock-solid, backwards compatible APIs on
| all levels. That way the work to maintain software would be
| much lower, making it possible to focus on doing some rare
| bug-fixing only. In open source in particular this should be
| a no-brainier, instead of all projects ruining things for
| each other by ignoring backwards compatibility.
| immibis wrote:
| The rock-solid backwards-compatible API would include, for
| example, being invoked with the command "screen -x", and
| being installed with "apt install screen" - at which point
| it's the same screen project under different management,
| not a new project.
| 3036e4 wrote:
| I was referring to the APIs required by screen itself to
| run. If screen is anything like any software I know
| anything about a fair amount of limited developer time
| has to be wasted on keeping up with random third-party
| stuff changing/breaking. Even if that is not the case, if
| we get more stable software in general that would mean
| maintainers of free software could take on more projects
| each, meaning there would be a higher probability that
| someone could be around to fix bugs in screen.
| unixplumber wrote:
| > 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.
|
| 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.
| immibis wrote:
| They are completely redesigning the UI to such an extent
| that it may as well be a completely new project.
|
| 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.
| criddell wrote:
| It's not necessarily sad for GNU tool development to stop
| (other than bug fixes, of course). I would take that as a sign
| that they are basically complete.
| lxgr wrote:
| Whether constant development is necessary or not largely
| depends on the surface area of your tool, both in terms of
| formal APIs it uses and external data formats and services.
| kstrauser wrote:
| Not quite in this case. Tmux was started by someone who
| wanted to update screen with new features but wasn't able to
| bend the code that far. I say this not out of spite or
| meanness, as I used screen for many happy years, but I'd say
| it's less complete and more abandoned. It still has
| maintainers but it seems to me that they're more "keep the
| lights on" than actively developing it.
| dundarious wrote:
| screen didn't even have vertical splits until maybe 5 or 10
| years ago. After tmux was already a solidly reliable
| replacement with vertical splits for years.
| wkat4242 wrote:
| True, this is why I switched to tmux.
| Kwpolska wrote:
| It's not sad if a good Stallman-free alternative exists. Like
| tmux.
| warpeggio wrote:
| So ... my tmux lifestyle is objectively superior in this one
| respect. Excellent.
| exploderate wrote:
| Yes, 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 wrote:
| I haven't done serial port stuff in many years, so I ask this
| in ignorance and I give you permission to laugh at my
| naivete. Can't you just run tip or something in a tmux or
| zellij window and have basically the same thing?
| pengaru wrote:
| > 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 wrote:
| From 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.
| remram wrote:
| I switched to tmux and I switched back due to the weird
| server/session/window/pane model that makes no sense and
| prevents me from showing different windows or layouts on
| different clients. 4 levels of objects is ridiculous and when
| you end up with less capabilities than screen, what are we
| doing?
|
| I would love to switch to a modern, maintained terminal
| multiplexer, but it would need to, well, be good at
| multiplexing.
| teddyh wrote:
| Note: In Debian, GNU screen is _not_ installed with setuid-root
| privileges.
| jesprenj wrote:
| Likewise in Gentoo. But in Gentoo it has SETGID for utmp group.
| Though I'm not sure what the implications are.
| JdeBP wrote:
| If 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
|
| 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.
| anthk wrote:
| I set TMPDIR to $HOME/tmp because of that.
| blueflow wrote:
| Except for the name, TMPDIR is unrelated to utmp.
| anthk wrote:
| I know; but it mitigates some potential race conditions.
| blueflow wrote:
| More info on that?
| ktm5j wrote:
| Looks like it is in Fedora.
| znpy wrote:
| I wonder if there is some selinux policy to reduce the attack
| surface
| JCattheATM wrote:
| There almost certainly is, pretty sure Fedora has an
| SELinux policy for all software in base.
| tmtvl wrote:
| Likewise in Arch.
| mlichvar wrote:
| On Fedora it is setgid screen, not root.
| jmclnx wrote:
| Slackware 15:
|
| 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
| perlgeek wrote:
| And the package in Debian Stable (aka bookworm) is too old to
| be affected by the vulnerabilities in 5.0.0.
|
| 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
| :-)
| mjevans wrote:
| Related...
| https://bugzilla.mozilla.org/show_bug.cgi?id=1966096
|
| 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.
| sillystuff wrote:
| The repo appears to be working for installing/updating
| packages. Mozilla should allow file listing which should
| fix the 404s, and make this repo behave as expected when
| manually browsed (Apparently hosted on a Google webserver;
| maybe Google forbids this?). 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
|
| Or, to really prove it to yourself, you can re-download the
| package: apt-get install --download-only
| --reinstall firefox
| mjevans wrote:
| I will have to look into that more tomorrow. My only
| Debian desktop is a laptop at family's house and
| currently asleep. It mentioned an error with the
| repository but my first troubleshooting step was to try
| to manually verify I could _get_ to the repo in a
| browser.
| foresto wrote:
| This is about Mozilla's builds of Firefox for Debian, not
| Debian's builds, right? So regular Debian users who run the
| default Firefox (firefox-esr) would be unaffected.
| mjevans wrote:
| Correct, but that's firefox-esr not firefox. At one point
| I found it necessary to switch as there was an issue with
| security updates, but that might have been an issue in
| that particular system's configuration that I since
| resolved.
| worldsavior wrote:
| Rendered version:
| https://security.opensuse.org/2025/05/12/screen-security-iss...
| jedimastert wrote:
| Here's the rendered blog post:
|
| https://security.opensuse.org/2025/05/12/screen-security-iss...
| mistrial9 wrote:
| so it appears that packaged Debian `screen` is not installed with
| root execution, therefore this entire situation is not a problem
| on Debian?
| zoobab wrote:
| I emailed the author of GNU Screen about the lack of proper
| documentation about the logging to a file feature:
|
| http://www.zoobab.com/screenrc
|
| GNU need a better issue tracking system :-)
| CelestialMystic wrote:
| There 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
| anthk wrote:
| Tmux has been in OBSD base side several releases and
| documented since the first one.
| CelestialMystic wrote:
| I know. I suggest you read the Q&A I posted.
| anthk wrote:
| Then:
|
| 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 wrote:
| I 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 wrote:
| I 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 wrote:
| tmux 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 wrote:
| Seeing screen popup reminded me of that one time I switched to
| tmux and forgot to use screen.
| sundarurfriend wrote:
| Zellij 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://github.com/zellij-org/zellij
| collinvandyck76 wrote:
| I 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 wrote:
| I 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 wrote:
| No, haven't tried recently, but will make a note to do so.
| Agree that a couple of years is an eternity :)
| kstrauser wrote:
| Right 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.
| lemonwaterlime wrote:
| 1. How many developers run all the most popular open source
| tools?
|
| 2. How much money is in the industries that use those tools?
| lowbloodsugar wrote:
| In 1990 we got told to stop using screen because other people
| could get into your sessions. Never used it again after that.
| nmz wrote:
| If 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 wrote:
| lines 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
| charcircuit wrote:
| Setuid 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.
| Pxtl wrote:
| Can screen just get completely tossed and converted into a
| compatibility-layer wrapper around tmux?
| indigodaddy wrote:
| Are there any official RedHat CVE pages for any of these screen
| vulns yet? Haven't found anything so far
| fistikcisahap wrote:
| RedHat removed screen from the distro repos starting from RHEL8
| and recommended tmux as the replacement.
|
| https://access.redhat.com/solutions/4136481
| indigodaddy wrote:
| It's still in EPEL I think but I guess that releases RH from
| having to address it?
| kazinator wrote:
| Funny 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.)
___________________________________________________________________
(page generated 2025-05-13 23:00 UTC)