Bugzilla – Full Text Bug Listing
|Summary:||VUL-0: CVE-2022-21946: cscreen: restrict usage of cscreen to a trusted set of users|
|Product:||[Novell Products] SUSE Security Incidents||Reporter:||Matthias Gerstner <matthias.gerstner>|
|Component:||Audits||Assignee:||Olaf Hering <ohering>|
|Status:||RESOLVED FIXED||QA Contact:||Security Team bot <security-team>|
|Priority:||P5 - None||CC:||matthias.gerstner, meissner, security-team|
|Found By:||---||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
|Bug Depends on:|
Description Matthias Gerstner 2022-02-24 14:21:14 UTC
+++ This bug was initially created as a clone of Bug #1196140 Currently cscreen ships this suoders rule: ```/etc/sudoers.d/cscreen ALL ALL=(_cscreen) NOPASSWD:/usr/bin/screen ``` This means that *any* user in the system including accounts like 'nobody' can attach to the shared screen session. This gives them also full access to the capabilities of the _cscreen user, like a proper home directory in /var/lib/cscreen where persistent data can be stored. Furthermore any shared information in existing cscreen sessions can be accessed, or arbitrary information can be placed into existing or newly created cscreen sessions. Installation of the cscreen package alone is enough to enable most of this attack surface. Starting the daemon process is only necessary for the permanent cscreen background session to become available. I recommend to adjust the cscreen package in a way that only members of a certain group are covered by the sudo rule. Ideally by introducing a separate group for this purpose (there already exists _cscreen, which could be used for this purpose).
Comment 1 Olaf Hering 2022-02-24 16:52:23 UTC
I think the entire point of this is that everyone who can login to the console server must also be able to attach to the cscreen. In case we want to go down the route of restricting access to users in the existing group _cscreen, how does the sudoers file need to look like?
Comment 2 Matthias Gerstner 2022-02-25 14:43:20 UTC
(In reply to Olaf Hering from comment #1) > I think the entire point of this is that everyone who can login to the > console server must also be able to attach to the cscreen. Yeah I get your use case, but between a security concern and a helpful feature there is hopefully some middle ground. You could choose to grant access to all members of the users group or some such. However that would still be kind of implicit, and that the fact that the cscreen package is installed alone suddently grants additional privileges makes me feel uneasy on this. > In case we want to go down the route of restricting access to users in the > existing group _cscreen, how does the sudoers file need to look like? A valid and hairy question given sudo's infamous syntax. This should do it: ``` %_cscreen ALL=(_cscreen) NOPASSWD:/usr/bin/screen ```
Comment 3 Olaf Hering 2022-02-25 16:16:54 UTC
So lets do this change to the sudoers file.
Comment 4 Johannes Segitz 2022-03-09 12:12:55 UTC
I pondered a bit if it makes sense to assign a CVE here. Matthias outlined some of the impact, additionally this grants access to the tty and dialout group to all users on the system. With all of that combined a CVE makes sense to me. Please use CVE-2022-21946 for this
Comment 5 Olaf Hering 2022-03-09 13:06:09 UTC
Comment 6 Olaf Hering 2022-03-09 13:09:32 UTC
I'm not sure if "just installing cscreen.rpm" will do any harm. But starting cscreen.service will indeed allow every user to attach to it.