Crashing VMware Guests with a Silly Filesystem Bug

A few months ago, I began digging into some VMware products — primarily VMware Fusion and VMware-tools. A number of issues found throughout my research were disclosed to the vendor, but what we’re talking about today is the finding in TRA-2020-38.

This issue is in the vmware-tools components regarding Shared Folders for macOS virtual machines. The issue itself is pretty silly, but was kinda fun to play with. It deals with being able to crash guest macOS VMs via a simple bug in the shared folders implementation.

Prerequisites for a VM to be vulnerable:

• Must be a macOS virtual machine (Windows and Linux virtual machines are not affected)
• Must have shared folders enabled (can be a folder/file located on the host itself or be a network share shared from the host to the guest)

So, what kinda crash are we talkin’? A full on kernel panic and reboot of the VM. See below:

Steps to replicate the above are as follows:

1. Create a file within a directory intended to be shared to the guest with a filename containing 128 or more colons. This filename is impractical, but illustrates the issue nicely. The share can be a remote network share if need be.
2. Share the directory to the guest.
3. Perform any action on the guest that would cause the HGFS kernel extension to process the filename (try to view the directory contents in Finder, run ls on the directory within a terminal, etc.).
4. Watch the guest crash.

So what’s going on here? Let’s take a look at open-vm-tools to find out. While this isn’t the exact codebase being used for macOS, it provides more than enough information to illustrate the root cause.

Within hgfsEscape., found here (open-vm-tools/hgfsEscape.c at 3a0205478e242bd672356d4eab6272d3b901fe6e · vmware/open-vm-tools · GitHub), we can see the following character substitutions intended for macOS implementations of HGFS:

#if defined __APPLE__
/* These characters are illegal in MAC OS file names. */
const char* HGFS_ILLEGAL_CHARS = “/:”;
const char* HGFS_SUBSTITUTE_CHARS = “!&”;
#else // __APPLE__
/* These characters are illegal in Linux file names. */
const char* HGFS_ILLEGAL_CHARS = “/“;
const char* HGFS_SUBSTITUTE_CHARS = “!”;
#endif // __APPLE__
#define HGFS_ESCAPE_CHAR ‘%’
#define HGFS_ESCAPE_SUBSTITUE_CHAR ‘]’

Further down in the file are the functions doEscape() and doUnescape() . The important bits are basically this: When processing shared files and folders, the HGFS implementation scans filenames for any illegal characters that the guest OS needs to be shielded from. If it finds one, it replaces the illegal character with its corresponding substitute and adds the escape character. To clarify, every illegal character effectively becomes two characters. No bounds checking is done on the translated filename to ensure that it conforms to size restrictions. If your filename goes over filesystem limitations (usually 255 characters), we’ll get a kernel panic as seen below:

panic(cpu 0 caller 0xffffff80036d29f2): “Kernel stack memory corruption detected”@/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.81.5/libkern/stack_protector.c:37
Backtrace (CPU 0), Frame : Return Address
0xffffff910f143550 : 0xffffff8002f3bb2b
0xffffff910f1435a0 : 0xffffff80030734d5
0xffffff910f1435e0 : 0xffffff8003064f4e
0xffffff910f143630 : 0xffffff8002ee2a40
0xffffff910f143650 : 0xffffff8002f3b217
0xffffff910f143750 : 0xffffff8002f3b5fb
0xffffff910f1437a0 : 0xffffff80036d2aa9
0xffffff910f143810 : 0xffffff80036d29f2
0xffffff910f143820 : 0xffffff8002eff899
0xffffff910f143830 : 0xffffff7f859e41b7
0xffffff910f143ad0 : 0xffffff7f859e6e45
Unaligned frame
Backtrace terminated-invalid frame pointer 0xffffff910f143b2f
Kernel Extensions in backtrace:
com.vmware.kext.vmhgfs(1538.95.92)[9FC86F3F-BCB6–37AD-A696-CCA1215F1377]@0xffffff7f859df000->0xffffff7f859e8fff

As far as I was able to determine, there is no security impact beyond a denial of service condition via crashing the guest. While the end result is a stack overflow in the kernel extension, I was unable to control this in any meaningful or exploitable way.

I’d like to take a moment to mention another oddity noticed during the above assessment. The use of colons in macOS file names is valid from OS X 10.10 onward. The HGFS implementation for macOS does not currently support this, which, other than the above DoS, causes other bugs to crop up. For example, if a file called hidden:file is placed in a folder shared to the guest, HGFS has no problem recognizing and processing the file, but the file is not visible or usable within the guest despite being valid.

For other macOS filesystem oddities, check out my previous blog on a similar topic of colon usage in filenames on macOS.