←back to thread

414 points st_goliath | 2 comments | | HN request time: 0.409s | 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 #
esseph ◴[] No.43979393[source]
Often for long running jobs you want to see the status of where logging out of the system stops the job output.
replies(1): >>43981783 #
qwertox ◴[] No.43981783[source]
Or where you can't risk dropping the terminal session, like during a system upgrade via SSH.
replies(1): >>43983776 #
esseph ◴[] No.43983776[source]
System upgrade shouldn't drop your session btw, at least not on most flavors I'm familiar with
replies(1): >>43984640 #
ycombobreaker ◴[] No.43984640[source]
The 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,
replies(2): >>43984757 #>>43990754 #
1. throwaway173738 ◴[] No.43984757[source]
A thoughtfully designed upgrade system doesn’t do the real work side your terminal session in the interactive process.
replies(1): >>43985242 #
2. ycombobreaker ◴[] No.43985242[source]
Defense in depth is always valuable. The point of this thread is that screen protects your workflow from an unexpected disconnection.