Multiple security issues in GNU Screen

(www.openwall.com)

414 points st_goliath | 2 comments | 13 May 25 11:28 UTC | HN request time: 0s | source

Show context

kazinator ◴[13 May 25 20:02 UTC] No.43977069[source]▶

Funny you should mention screen and setuid. In one installation, I had to give screen chmod u+s perms to solve some weird issue, thinking what a gross thing to do.

Turns out, it has features dependent on setuid, and some systems ship it that way? Yikes!

(But, after I gave u+s to screen, it reads root's ~/.screenrc instead of mine (which I accepted as part of the workaround). Maybe that particular build of screen I'm using doesn't react properly to setuid; maybe it has to be built a certain way also to enable that support.)

replies(1): >>43978875 #

1. sweeter ◴[13 May 25 23:13 UTC] No.43978875[source]▶

>>43977069 #

Nope, that's exactly how setuid works. You're setting the [s]pecial bit on a binary to tell the system to always run it as the provided [u]ser

replies(1): >>43979370 #

2. kazinator ◴[14 May 25 00:17 UTC] No.43979370[source]▶

>>43978875 (TP) #

Nope, setuid programs have an effective UID as the owner (often root), but also have the real user ID of the original user. Programs intended for setuid operation pay attention to this; it is very important. They can use to to perform certain operations under privilege and then permanently drop to the original user.

↑