←back to thread

Multiple security issues in GNU Screen

(www.openwall.com)
414 points st_goliath | 9 comments | 13 May 25 11:28 UTC | HN request time: 0s | source | bottom
Show context
RMPR ◴[13 May 25 11:51 UTC] No.43971862[source]▶
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.

replies(4): >>43971918 #>>43971987 #>>43973735 #>>43977030 #
dooglius ◴[13 May 25 12:08 UTC] No.43971987[source]▶
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.

replies(5): >>43972036 #>>43972445 #>>43972504 #>>43973108 #>>43975717 #
JdeBP ◴[13 May 25 12:14 UTC] No.43972036[source]▶
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/

replies(2): >>43972131 #>>43979137 #
ngangaga[dead post] ◴[13 May 25 12:26 UTC] No.43972131[source]▶
[flagged]
entropie ◴[13 May 25 13:14 UTC] No.43972586{3}[source]▶
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.
replies(4): >>43972845 #>>43973094 #>>43973786 #>>43979384 #
dbdoskey ◴[13 May 25 15:07 UTC] No.43973786{4}[source]▶
A similar process is happening with zellij and tmux. Since I switched over I feel that tmux is obsolete.
replies(3): >>43973811 #>>43974148 #>>43974216 #
1. fullstop ◴[13 May 25 15:39 UTC] No.43974148{5}[source]▶
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.

replies(2): >>43974914 #>>43974987 #
2. spookie ◴[13 May 25 16:46 UTC] No.43974914[source]▶
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.
replies(1): >>43976361 #
3. kstrauser ◴[13 May 25 16:51 UTC] No.43974987[source]▶
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.

replies(1): >>43976310 #
4. fullstop ◴[13 May 25 18:51 UTC] No.43976310[source]▶
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.

replies(1): >>43976476 #
5. fullstop ◴[13 May 25 18:56 UTC] No.43976361[source]▶
Hopefully some effort is eventually put into slimming things down.
6. kstrauser ◴[13 May 25 19:09 UTC] No.43976476{3}[source]▶
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.

replies(3): >>43977274 #>>43977421 #>>43978594 #
7. int_19h ◴[13 May 25 20:22 UTC] No.43977274{4}[source]▶
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.

8. fullstop ◴[13 May 25 20:36 UTC] No.43977421{4}[source]▶
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.
9. fc417fc802 ◴[13 May 25 22:43 UTC] No.43978594{4}[source]▶
> 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.