Redhat ships with a targeted policy. Most of the non-network programs are put in a very permissive domain to avoid breakage.
I just checked the CentOS policy[0] (not at work and don't have easy access to the Redhat repos).
It appears that xserver_t does have write access to both etc_t and shadow_t [1].
More specifically, xserver_t is part of the selinux_unconfined_type attribute, which means that it can do pretty much anything. (Even more specifically, it is part of the files_unconfined_type attribute, which gives it write permissions to everything in file_type):
That 271 byte file is just a shell script that execs either Xorg.wrap or Xorg from the X basedir (eg /usr/lib/xorg/). One of those target files is usually setuid.
If you have Xorg.wrap, it will be the setuid file and it is usually configured to drop root before executing the real Xorg if root isn't needed (eg. KMS is available).
Some people (like me) are visual learners / auditory learners and Computerphile caters to that niche of learners. This is why I prefer videos/audio over tangible books that you can hold. It is also common to see me putting blogposts into text-to-speech programs and then I listen to them at night or on the train.
We are naturally inclined to have certain biases towards different learning styles. It's really a psychology issue. What bothers me about these studies that claim we should 'work harder' on our weaknesses (i.e visual learners should read more books/text) - is that we should also build on strength.
When you bolster one learning style and neglect the other, but learn more in the process of the preferred learning style, then why not see it to the end, and understand / digest the knowledge gained?
I guess it is about balance. If I am a pure visual (or auditory) learner, then surely I would have learned that books/text have their place. I imagine that the greatest learners out there use all the learning styles but still have a bias towards their learning style. How pronounced that bias is, is still unknown.
Sure, there are accessibility issues for people like you, but the density of text cannot be overstated. Imagine transformig a textbook with all of its details into videos with explanations at the same level of detail. It's a gargantuan task and the playtime of such content would be in the order of years, not hours.
One way I got root recently, aside from pivoting on a setuid 0 binary, was calling seteuid(0). The vendor's program manager on the device forgot to setuid(user_id), it only seteuid(user_id). So going back to root was as easy as seteuid(0). The joy of real and effective process user. :)
Other easy way, if you have a way to provide your own filesystem to the device (via SD card for example), is to just put an Ext filesystem on it, and add your own setuid 0 binary there. Device makers sometimes don't know what they're doing, so they don't mount untrusted removable devices with -o nosuid,noexec,nodev ...
That works even if there's no usable setuid 0 binary on the rootfs.
It doesn't help my confidence in the world, that this was a PoS terminal device from a self described "Leader in Payment Terminals". But hey, they even read random files on the filesystem from a kernel USB device driver, and they probably got to the market first, so that's what matters.
Thankfully, AFAIK, this particular device is not sold anymore.
In a marathon, the leader is not so much the healthiest of the bunch.
Also, this is a PoS terminal, if there's any wonder left in you for how they could mess this up so bad, I'm guessing this is the first one you've seen. ;- )
Yes, the first one. One thing I liked about it though is that the vendor uses uniform ioctl calling convention for pretty much everything they implement in the kernel, so I have modified strace to decode their ioctl payload, and I was able to rewrite most of their library code with my implementation, with the help of traces of their demo app. Now I can drop their complicated and buggy userspace code completely and use my own rootfs.
The kernel is harder, since they also violate GPL and don't provide kernel source code along with their terminal, and neither does their SoC vendor.
The exploit is overwriting /etc/shadow with the log of Xorg. If you pass the right string somehow you overwrite the root password. The trick is setting the font path and the font path appears in the log. Of course this fills /etc/shadow with a lot of bogus data, but one line in the log which describes the root password is enough. Xorg can overwrite /etc/shadow when it is setuid root.
Attention: don't attempt it on a system you need. The exploit is destroying all user's passwords. Or at least make a copy of /etc/shadow before trying.
Aside form a manual backup, it appears that Xorg will create an `/etc/shadow.old` file (at least on the system I tested) that can be restored once root access is gained.
> The exploit is overwriting /etc/shadow with the log of Xorg.
That took me couple of seconds to read and I got virtually the same information as the 11 minute video. I think there's no question about which way of doing things is more efficient.
I am not sure I quite got your question, and had a very succinct look at the video, but passwd is being used here as a way to check whether the user has root access.
It is important to note that this exploit is an old one, has been known for a while, and is one of the things being addressed by switching to Wayland.
That said, a lot of work has been done towards running X11 rootless (Arch for instance [1]). That should be possible as long as you use DRI, as far as I know (which is the case if you use a graphics card less than about ~10-20 years old, depending on the brand).
* SECURITY UPDATE: Privilege escalation and file overwrite
- debian/patches/CVE-2018-14665.patch: disable -logfile and -modulepath
when running with elevated privileges in
hw/xfree86/common/xf86Init.c.
- CVE-2018-14665
-- Marc Deslauriers <marc.deslauriers@ubuntu.com> Thu, 25 Oct 2018 11:18:32 -0400
Xorg might not be the only exploitable software. Here the approach to search for other exploits:
1. Is the software setuid-root?
2. Does the software stay as root?
3. Can you make it write a user description line like as in /etc/shadow?
4. Can you direct it to write to /etc/shadow?
An example: Xorg is setuid-root and stays as root. Pass it the root's description line as a (bogus) font path and it will write an error message. Redirect the error message to /etc/shadow and your exploit is finished.
I am afraid that other setuid-root programs could be exploitable.
38 comments
[ 3.6 ms ] story [ 73.8 ms ] threadhttps://gitlab.freedesktop.org/xorg/xserver/commit/50c0cf885...
I just checked the CentOS policy[0] (not at work and don't have easy access to the Redhat repos).
It appears that xserver_t does have write access to both etc_t and shadow_t [1].
More specifically, xserver_t is part of the selinux_unconfined_type attribute, which means that it can do pretty much anything. (Even more specifically, it is part of the files_unconfined_type attribute, which gives it write permissions to everything in file_type):
[0] https://centos.pkgs.org/7/centos-updates-x86_64/selinux-poli...[1] Because of its sensitive nature, /etc/shadow has its own SELinux label
you can open a dri render device node, and use it directly
If you have Xorg.wrap, it will be the setuid file and it is usually configured to drop root before executing the real Xorg if root isn't needed (eg. KMS is available).
innovative way of using X11.
https://www.theregister.co.uk/2018/10/25/x_org_server_vulner...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1466...
https://lists.x.org/archives/xorg-announce/2018-October/0029...
No evidence to back idea of learning styles
https://www.theguardian.com/education/2017/mar/12/no-evidenc...
When you bolster one learning style and neglect the other, but learn more in the process of the preferred learning style, then why not see it to the end, and understand / digest the knowledge gained?
I guess it is about balance. If I am a pure visual (or auditory) learner, then surely I would have learned that books/text have their place. I imagine that the greatest learners out there use all the learning styles but still have a bias towards their learning style. How pronounced that bias is, is still unknown.
Go find your own article if it bothers you.
Other easy way, if you have a way to provide your own filesystem to the device (via SD card for example), is to just put an Ext filesystem on it, and add your own setuid 0 binary there. Device makers sometimes don't know what they're doing, so they don't mount untrusted removable devices with -o nosuid,noexec,nodev ...
That works even if there's no usable setuid 0 binary on the rootfs.
Thankfully, AFAIK, this particular device is not sold anymore.
In a marathon, the leader is not so much the healthiest of the bunch.
Also, this is a PoS terminal, if there's any wonder left in you for how they could mess this up so bad, I'm guessing this is the first one you've seen. ;- )
The kernel is harder, since they also violate GPL and don't provide kernel source code along with their terminal, and neither does their SoC vendor.
Attention: don't attempt it on a system you need. The exploit is destroying all user's passwords. Or at least make a copy of /etc/shadow before trying.
That took me couple of seconds to read and I got virtually the same information as the 11 minute video. I think there's no question about which way of doing things is more efficient.
It is important to note that this exploit is an old one, has been known for a while, and is one of the things being addressed by switching to Wayland.
That said, a lot of work has been done towards running X11 rootless (Arch for instance [1]). That should be possible as long as you use DRI, as far as I know (which is the case if you use a graphics card less than about ~10-20 years old, depending on the brand).
[1] https://wiki.archlinux.org/index.php/Xorg#General
xorg-server (2:1.19.6-1ubuntu4.2) bionic-security; urgency=medium
1. Is the software setuid-root?
2. Does the software stay as root?
3. Can you make it write a user description line like as in /etc/shadow?
4. Can you direct it to write to /etc/shadow?
An example: Xorg is setuid-root and stays as root. Pass it the root's description line as a (bogus) font path and it will write an error message. Redirect the error message to /etc/shadow and your exploit is finished.
I am afraid that other setuid-root programs could be exploitable.
setuid-root is extremely dangerous.