←back to thread

414 points st_goliath | 1 comments | | HN request time: 0s | source
Show context
RMPR ◴[] 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 #
trollied ◴[] No.43971918[source]
Yup, screen -x
replies(1): >>43972171 #
qwertox ◴[] No.43972171[source]
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.
replies(1): >>43972353 #
trollied ◴[] No.43972353[source]
I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
replies(1): >>43973717 #
johnmaguire ◴[] No.43973717[source]
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.)
replies(2): >>43979393 #>>43982662 #
1. magicalhippo ◴[] No.43982662{3}[source]
I use screen almost by default when connecting over SSH, but I've never used -x and didn't know about it.

Habbit from back in the dial-up days when connections got dropped quite frequently. Still relevant with laptop going into sleep mode and such.

So nice to just resume wherever you were as of nothing happened. Or to run jobs in the background, like long compiles, without an additional SSH session.