Most active commenters
  • immibis(4)
  • mmsc(3)
  • Wowfunhappy(3)
  • kstrauser(3)

←back to thread

Multiple security issues in GNU Screen

(www.openwall.com)
414 points st_goliath | 55 comments | 13 May 25 11:28 UTC | HN request time: 1.453s | source | bottom
1. mmsc ◴[13 May 25 12:05 UTC] No.43971967[source]▶
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?

replies(5): >>43972042 #>>43972071 #>>43972387 #>>43972604 #>>43972925 #
2. Trasmatta ◴[13 May 25 12:14 UTC] No.43972042[source]▶
> 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.

replies(2): >>43972149 #>>43972283 #
3. croemer ◴[13 May 25 12:18 UTC] No.43972071[source]▶
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.
replies(1): >>43972085 #
4. mmsc ◴[13 May 25 12:20 UTC] No.43972085[source]▶
TFA says upstream asked for the review.
replies(2): >>43973006 #>>43975307 #
5. tecleandor ◴[13 May 25 12:27 UTC] No.43972149[source]▶
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
6. mmsc ◴[13 May 25 12:42 UTC] No.43972283[source]▶
Seems like a prime target for Jia Tan.
7. jzb ◴[13 May 25 12:51 UTC] No.43972387[source]▶
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.
replies(1): >>43973007 #
8. immibis ◴[13 May 25 13:16 UTC] No.43972604[source]▶
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.

replies(3): >>43972716 #>>43973459 #>>43974235 #
9. Wowfunhappy ◴[13 May 25 13:27 UTC] No.43972716[source]▶
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).
replies(4): >>43972924 #>>43973023 #>>43974844 #>>43975292 #
10. kevin_thibedeau ◴[13 May 25 13:44 UTC] No.43972924{3}[source]▶
Tmux doesn't support serial ports.
replies(4): >>43973045 #>>43973196 #>>43974241 #>>43982081 #
11. criddell ◴[13 May 25 13:44 UTC] No.43972925[source]▶
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.
replies(4): >>43973934 #>>43973991 #>>43975601 #>>43976373 #
12. croemer ◴[13 May 25 13:51 UTC] No.43973006{3}[source]▶
Right, I got the direction wrong.
13. marcosdumay ◴[13 May 25 13:51 UTC] No.43973007[source]▶
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.

replies(3): >>43973635 #>>43974787 #>>43975209 #
14. marcosdumay ◴[13 May 25 13:54 UTC] No.43973023{3}[source]▶
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.
15. PhilipRoman ◴[13 May 25 13:56 UTC] No.43973045{4}[source]▶
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.
replies(2): >>43973413 #>>43973708 #
16. nottorp ◴[13 May 25 14:11 UTC] No.43973196{4}[source]▶
I'm sure a rewrite of screen in Rust will be 105% secure. And won't support serial ports either.
17. kevin_thibedeau ◴[13 May 25 14:31 UTC] No.43973413{5}[source]▶
It isn't separate functionality. Terminals connected via serial port is a valid use case for a terminal multiplexor.
replies(1): >>43973724 #
18. 3036e4 ◴[13 May 25 14:36 UTC] No.43973459[source]▶
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.
replies(1): >>43974061 #
19. megous ◴[13 May 25 14:53 UTC] No.43973635{3}[source]▶
It's not large:

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

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

20. JdeBP ◴[13 May 25 15:00 UTC] No.43973708{5}[source]▶
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.
21. PhilipRoman ◴[13 May 25 15:01 UTC] No.43973724{6}[source]▶
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.

replies(1): >>43989062 #
22. lxgr ◴[13 May 25 15:21 UTC] No.43973934[source]▶
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.
23. kstrauser ◴[13 May 25 15:27 UTC] No.43973991[source]▶
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.
24. immibis ◴[13 May 25 15:32 UTC] No.43974061{3}[source]▶
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.
replies(1): >>43974356 #
25. unixplumber ◴[13 May 25 15:47 UTC] No.43974235[source]▶
> 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.

replies(1): >>43975910 #
26. im3w1l ◴[13 May 25 15:47 UTC] No.43974241{4}[source]▶
What is a serial port and what do you use it for?
replies(3): >>43974541 #>>43976309 #>>43980115 #
27. 3036e4 ◴[13 May 25 15:59 UTC] No.43974356{4}[source]▶
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.
28. genewitch ◴[13 May 25 16:15 UTC] No.43974541{5}[source]▶
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).

29. doctoboggan ◴[13 May 25 16:36 UTC] No.43974787{3}[source]▶
What are the replacement tools I should be looking at as a casual user of screen?
replies(2): >>43975021 #>>43975066 #
30. rzr ◴[13 May 25 16:41 UTC] No.43974844{3}[source]▶
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

31. nosrepa ◴[13 May 25 16:54 UTC] No.43975021{4}[source]▶
Tmux
replies(1): >>43979276 #
32. kstrauser ◴[13 May 25 16:57 UTC] No.43975066{4}[source]▶
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.

replies(1): >>43975837 #
33. narag ◴[13 May 25 17:09 UTC] No.43975209{3}[source]▶
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 :-)

34. layer8 ◴[13 May 25 17:15 UTC] No.43975292{3}[source]▶
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.
replies(1): >>43979196 #
35. Eduard ◴[13 May 25 17:16 UTC] No.43975307{3}[source]▶
"TFA"?
replies(1): >>43975604 #
36. dundarious ◴[13 May 25 17:42 UTC] No.43975601[source]▶
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.
replies(1): >>43976656 #
37. shawn_w ◴[13 May 25 17:42 UTC] No.43975604{4}[source]▶
The Fine Article
38. bombcar ◴[13 May 25 18:03 UTC] No.43975837{5}[source]▶
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.

replies(5): >>43976434 #>>43977409 #>>43980022 #>>43982417 #>>43987484 #
39. immibis ◴[13 May 25 18:10 UTC] No.43975910{3}[source]▶
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.

40. spauldo ◴[13 May 25 18:51 UTC] No.43976309{5}[source]▶
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.

41. Kwpolska ◴[13 May 25 18:57 UTC] No.43976373[source]▶
It's not sad if a good Stallman-free alternative exists. Like tmux.
42. kstrauser ◴[13 May 25 19:05 UTC] No.43976434{6}[source]▶
Along the lines of Mosh, I've migrated from it to Eternal Terminal (ET): https://eternalterminal.dev
43. wkat4242 ◴[13 May 25 19:26 UTC] No.43976656{3}[source]▶
True, this is why I switched to tmux.
44. int_19h ◴[13 May 25 20:34 UTC] No.43977409{6}[source]▶
If that is literally the only thing that you need, dtach is the ticket.
45. Wowfunhappy ◴[13 May 25 23:53 UTC] No.43979196{4}[source]▶
> If anything, a package “tmux-as-screen” could be provided for those who want 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".

replies(1): >>43979282 #
46. jmholla ◴[14 May 25 00:05 UTC] No.43979276{5}[source]▶
If there was a way to get rid of Tmux's persistent status bar, I'd be happy to switch over. But last time I checked, you can't, and I want that real estate.
replies(1): >>43980017 #
47. layer8 ◴[14 May 25 00:06 UTC] No.43979282{5}[source]▶
In that case, nobody would be tricked because they would have to explicitly select that package. Those already having screen installed, or selecting screen for installation, wouldn’t automatically be upgraded to tmux-as-screen. So what the comment you replied to mentioned as a problem of inertia and there being “no immediate incentive to switch” would remain largely unaddressed.
replies(1): >>43979335 #
48. Wowfunhappy ◴[14 May 25 00:13 UTC] No.43979335{6}[source]▶
Well, I guess the other part would be removing screen from the official repo. So the original utility is gone, but we have a compatibility package you can install that should make things work like they used to. (Of course, if you really still want screen you can build from source or some such.)
49. arp242 ◴[14 May 25 02:12 UTC] No.43980017{6}[source]▶
Add "set -g status" to your tmux.conf. You can even bind it to a key to toggle if you want.
50. arp242 ◴[14 May 25 02:14 UTC] No.43980022{6}[source]▶
> 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 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.

51. cozzyd ◴[14 May 25 02:31 UTC] No.43980115{5}[source]▶
console=ttyS0,115200
52. immibis ◴[14 May 25 08:01 UTC] No.43982081{4}[source]▶
Just use minicom
53. db48x ◴[14 May 25 08:59 UTC] No.43982417{6}[source]▶
Even screen is too powerful for that use case. Just use nohup or dtach instead.
54. lupusreal ◴[14 May 25 18:06 UTC] No.43987484{6}[source]▶
Screen has some obscure functionality that tmux doesn't have. Handling serial port connections, whereas with tmux AFAIK you'd have to use minicom.
55. throwaway173738 ◴[14 May 25 20:49 UTC] No.43989062{7}[source]▶
I dont think you understand what a terminal is. What you’re talking about is a shell running in a console. What we’re talking about is the terminal to connect to the console serial port running the shell.

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