Linxz' Blog

Still trying to think of something witty, I will let you know once I get something...

Home Blog Categories
16 January 2019 | 4 minutes to read

Xorg CVE 2018-14665

Tags: priv esc - exploit

Introduction

On October 25th 2018 a post was made on SecurityTracker disclosing CVE2018-14665. The interesting thing is this CVE has two bugs in two different arguments. The first is a flaw in the -modulepath argument which could lead to arbitary code being executed on the system. The second was a flaw in the -logfile arugment which could allowed arbitary files to be deleted on the system, both of these issues were caused by poor command line validation.

So, how does it work?

It is worth noting that the reason this can be used for privlege escalation is because both of these processes are root processes meaning when they are run they will run as root, this is why it is possible for us to gain root access, the problem was that the program was not correctly checking whether the user is already root or not before running these processses, we will look into that a bit later when we do the code review.

Okay, so let us start first with the -modulepath and what this argument actually does which is going to help us understand how we actually exploit this vulnerability. All the -modulepath argument does is allow us to set a directory to search for Xorg server modules (I know you’re already thinking about how this can be exploited and why it’s bad to allow such a function to a user who isn’t root). Now, as we mentioned earlier this argument is a privileged process, so imagine if we could set this to an insecure path? Well, we can! From there we can get the process to run code that is unprivileged but as we said, it’s running a privileged process!

So what about the -logfile arguemnt? All this does is set a new log file for the Xorg server instead of using the default log file that is found in /var/log. You’re probably wondering how we can exploit this? Well this will actually allow us to overwrite files such as /etc/shadow if we can overwrite this file then there is a massive problem, for example we could allow the root user to login without authentication taking place! Much like the -modulepath flag, -logfile is also a privileged process, hence why it is a problem that an unprivileged user can use this switch!

As you can see, this exploit seems to be pretty devestating, we have two potential methods for priv-esc on a vulnerable system which is very nice! So what are the downsides? Well, it would seem that the biggest downside is you can only run this on a console session and not via SSH, at least it would seem that way on Red Hat systems running Xorg. This is due to a default module called PAM (Pluggable Authentication Module) however, researcher Matthew Hickey found that on affected OpenBSD systems you can exploit this vulnerability over SSH, you can find his tweet here which includes a copy of the .sh script that allows you to exploit this vulnerability.

Code Review

Now, let’s get into a brief code review! There really is not much to review here because this bug is very, very simple and has a very, very simple fix! It seems that little things always go unnoticed yet sometimes can have massive consequences! In this case the consequence is two LPEs.

You can find all of the code I am about to review on the Xorg GitLab repo, the commit we’re about to look at is commit 50c0cf88. As you can see, the issue was found in xf86Init.c

    /* First the options that are not allowed with elevated privileges */
    if (!strcmp(argv[i], "-modulepath")) {
        CHECK_FOR_REQUIRED_ARGUMENT();
        xf86CheckPrivs(argv[i], argv[i + 1]);
        xf86ModulePath = argv[i + 1];
        xf86ModPathFrom = X_CMDLINE;
        return 2;
    }
    if (!strcmp(argv[i], "-logfile")) {
        CHECK_FOR_REQUIRED_ARGUMENT();
        xf86CheckPrivs(argv[i], argv[i + 1]);
        xf86LogFile = argv[i + 1];
        xf86LogFileFrom = X_CMDLINE;
        return 2;
    }

The code above is where the bug lies, as you can see there is actually no check to see whether the user executing the flag has permission to run it, given that this is a privileged flag it means that whilst it is running, it is running as root, this would not be a problem if we were actually checking whether the user running the option already has root privilege.

References

Matthew Hickey OpenBSD LPE SSH Exploit GitLab Fix Commit