CVE-2009-1143 - Exploiting a Symlink Race in open-vm-tools (Mounting Shares Gone Wrong)

In the world of virtualization, open-vm-tools has been a backbone utility for VMware users operating on Linux. But back in 2009, a serious bug was found: CVE-2009-1143. This flaw gave curious (or malicious) local users a way to bypass share-mounting restrictions using a clever symlink trick and a race condition in the mount.vmhgfs utility. In this post, we'll break down what happened, show some code, guide you through the exploit scenario, and explain why this matters—all in simple terms.

What is open-vm-tools and mount.vmhgfs?

open-vm-tools is a set of tools used to make Linux play nice inside VMware virtual machines. One component, mount.vmhgfs, lets users access "shared folders" between the host (outside the VM) and the guest (inside the VM).

Normally, there are checks to stop regular users from mounting just anything as a shared folder (you don't want everyone accessing sensitive directories). But a bug slipped into version 2009.03.18-154848.

CVE-2009-1143: The Bug Explained

The vulnerability was caused by a race condition in how mount.vmhgfs worked with symlinks. Here’s how:

- When a local user asked to mount a host share into the VM at a directory, mount.vmhgfs would resolve the final path with the realpath() function, to avoid following symlinks that could trick it.
- But there was a tiny window—between resolving the path and doing the mount—where an attacker could quickly swap a regular directory with a symlink pointing somewhere else (like /etc), before the mount happened.
- This is called a TOCTOU (Time-of-Check to Time-of-Use) bug: it checks "is this OK?" and uses it a moment later, but in between, things might have changed.

Here’s a snippet similar to what you’d find in mount.vmhgfs

// Simplified logic
char real_mountpoint[PATH_MAX];
realpath(user_given_path, real_mountpoint);

// [Time window: attacker swaps the path here]

mount("hostMount", real_mountpoint, ...);

The problem? Between realpath() and mount(), an attacker could replace the directory at user_given_path with a symlink to, say, /etc.

How Could an Attacker Exploit This?

Suppose a local user (not root) wants to mount a VMware share on /tmp/myshare but wants it to mount on /etc instead (which should not be allowed).

Here's an outline of a possible attack

1. Create a Directory: First, create /tmp/myshare as a real directory.
2. Ask root or a tool to mount: Trigger mount.vmhgfs host:/share /tmp/myshare.
3. Race the System: In the split-second after mount.vmhgfs checks /tmp/myshare but before it’s mounted, quickly remove /tmp/myshare and symlink it to /etc.
4. Result: The share is mounted on /etc, overlaying system files. That can allow rewriting critical configs or other attacks, depending on share contents and permissions.

Example Race Condition in Bash Pseudocode

mkdir /tmp/myshare
# In one terminal, start mounting (triggering mount.vmhgfs)
# In another terminal, run:
while true; do
    rm -rf /tmp/myshare
    ln -s /etc /tmp/myshare
done

This loop rapidly swaps the directory with a symlink, hoping to catch the short window in which mount.vmhgfs has resolved the path but not performed the mount.

Why is this a Big Deal?

Mounting on /etc or /root, even temporarily, can let a user break the VM, install backdoors, wipe config files, or escalate privileges. This kind of race is a classic unsafe pattern.

References

- MITRE CVE-2009-1143
- USN-761-1: open-vm-tools vulnerability
- open-vm-tools Changelog

Conclusion

CVE-2009-1143 is a classic example of why TOCTOU (Time of Check to Time of Use) bugs are so dangerous, especially when attackers can race the system. If you’re running old VMware guest tools—or any program that uses setuid and file paths—be aware of symlink races!

Always keep software updated, and check for setuid tools that follow risky patterns.

*Want to see another detailed breakdown of a classic Linux bug? Leave a comment!*

Timeline

Published on: 11/23/2022 18:15:00 UTC
Last modified on: 11/28/2022 18:22:00 UTC