Hi All!
There is a new interesting CVE.
An incorrect permission check for -modulepath and -logfile options when starting Xorg X server allows unprivileged users with the ability to log in to the system via physical console to escalate their privileges and run arbitrary code under root privileges.
Hmm, looks pretty interesting… Can SELinux help here? Let’s see.
I found a nice blog about this Vulnerability:
https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html
With information from the blog post, I prepared Red Hat Enterprise Linux 7.5 Workstation and started with the investigation.
I’ll skip technical details about this vulnerability, you can read the blog mentioned above, but let’s try to gain root privileges.
I tried fresh installation of the system with default SELinux configuration. The attack was successful because of this allow rule:
$ sesearch -A -s xserver_t -t shadow_t -c file -p write
allow files_unconfined_type file_type:file { append audit_access create execute execute_no_trans getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr swapon unlink write };
Here we can see the main problem. xserver_t SELinux domain is part of files_unconfined_type attribute.
Since we didn’t want to block users from freely configuring their system environment, we ship the xserver_t domain as unconfined_domain by default. But system administrators are encouraged to remove the attribute once the system configuration is done and add any new rules required by it if necessary. See for example on how to do it. Let’s now see what happens when we disable unconfined_domain.
# semodule -d unconfined
# semodule -lfull | grep unconfined
100 unconfined pp disabled
Let’s try to reproduce the exploit:
$ cd /etc/; Xorg -fp "root::16431:0:99999:7:::" -logfile shadow :1
$
What happened? Nothing happened because of SELinux! “/etc/shadow” file remained untouched:
$ ls -Z | grep shadow
----------. root root system_u:object_r:shadow_t:s0 gshadow
----------. root root system_u:object_r:shadow_t:s0 gshadow-
----------. root root system_u:object_r:shadow_t:s0 shadow
----------. root root system_u:object_r:shadow_t:s0 shadow-
In audit log there is a proof that SELinux denied X server to write to /etc/shadow:
# ausearch -m AVC -ts recent | grep shadow
type=AVC msg=audit(1541111364.200:593): avc: denied { write } for pid=6259 comm="Xorg" name="shadow" dev="dm-0" ino=18086774 scontext=unconfined_u:unconfined_r:xserver_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shadow_t:s0 tclass=file
This is another example why it is a really good idea to spend some time to configure SELinux on your system. 🙂