SSD Advisory – Ubuntu LightDM Guest Account Local Privilege Escalation

Credit to Author: Maor Schwartz| Date: Tue, 18 Apr 2017 10:00:24 +0000

Want to get paid for a vulnerability similar to this one?
Contact us at: sxsxdx@xbxexyxoxnxdxsxexcxuxrxixtxy.xcom

Vulnerability Summary
The following advisory describes a local privilege escalation via LightDM found in Ubuntu versions 16.10 / 16.04 LTS.

Ubuntu is an open source software platform that runs everywhere from IoT devices, the smartphone, the tablet and the PC to the server and the cloud. LightDM is an X display manager that aims to be lightweight, fast, extensible and multi-desktop. It uses various front-ends to draw login interfaces, also called Greeters.

Credit
An independent security researcher, G. Geshev (@munmap), has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program

Vendor Responses
The vendor has released a patch to address this issue.
For more information: https://www.ubuntu.com/usn/usn-3255-1/

CVE Details
CVE-2017-7358

Vulnerability Details
The vulnerability is found in LightDM, which is the Ubuntu’s default desktop manager, more specifically in the guest login feature. By default LightDM allows you to log into a session as a temporary user. This is implemented in a script called ‘guest-account‘.

The script runs as root when you view the login screen, also known as a greeter, to log in as a guest. Ubuntu’s default greeter is Unity Greeter.

Vulnerable code

The vulnerable function is ‘add_account‘.

The guest folder gets created using ‘mktemp’ on line 35. The attacker can use ‘inotify‘ to monitor ‘/tmp‘ for the creation of this folder.

The folder name will likely contain both upper and lower case letters. Once this folder is created, we grab the folder name and quickly and create the equivalent folder with all letters lower case.

If we manage to race the ‘mv‘ command on line 38, we end up with the newly created home for the guest user inside the folder we own.

Once we have the guest home under our control, we rename it and replace it with a symbolic link to a folder we want to take over. The code below will then add the new user to the OS. The user’s home folder will already point to the folder we want to take over, for example ‘/usr/local/sbin‘.

The attacker can grab the newly created user’s ID and monitor ‘/usr/local/sbin‘ for ownership changes. The ownership will be changed by the following ‘mount‘.

We will remove the symbolic link and create a folder with the same name – to let the guest user to log in. While the guest is logging in, his path for finding executable files will include ‘bin‘ under his home folder.

That’s why we create a new symbolic link to point his ‘bin‘ into a folder we control. This way we can force the user to execute our own code under his user ID. We use this to log out the guest user from his session which is where we can gain root access.

The logout code will first execute the following code:

This code will be executed as the owner of the script, i.e. root. Since we have already taken over ‘/usr/local/sbin‘ and have planted our own ‘getent‘, we get to execute commands as root at this point.

Note – We can trigger the guest session creation script by entering the following two commands.

Proof of Concept

The Proof of Concept is contains 9 files and they will take advantage of the race conditions mentioned above.

  1. kodek/bin/cat
  2. kodek/shell.c
  3. kodek/clean.sh
  4. kodek/run.sh
  5. kodek/stage1.sh
  6. kodek/stage1local.sh
  7. kodek/stage2.sh
  8. kodek/boclocal.c
  9. kodek/boc.c

By running the following scripts an attacker can run root commands:

If the exploit fails, you can simply run it again.

Once you get your root shell, you can optionally clean any exploit files and logs by executing the below.

boc.c

boclocal.c

clean.sh

run.sh

shell.c

stage1.sh

stage1local.sh

stage2.sh

/bin/cat

https://blogs.securiteam.com/index.php/feed