←back to thread

414 points st_goliath | 1 comments | | HN request time: 0.206s | 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. esseph ◴[] No.43990754[source]
You're not wrong, but largely in the virtualized world we live in, it matters less and less when you have a virtual console.

That said the sshd session you are connected on is still running the old executable until the service is restarted AND your session ends, so even if sshd gets upgraded, you should still be good to go.