Hi, I'm sorry I just let this stay without a follow-up at the time. I am CC'ing John Wolfe now, who authored the patch commit.
I do think the fix was incomplete. As someone wrote to me off-list at the time (didn't want to post publicly, so I post without attribution): > I let the oher person respond publicly, but the open-vm-tools runs in the VM > as > a service and communicates with VMware. So it is both risk to the VM itself > and > to the VMware ESXi (or vCenter). To me, this means that the risk of race conditions applies. Alexander On Tue, May 13, 2025 at 03:59:57AM +0200, Solar Designer wrote: > Hi, > > Thank you very much VMware PSIRT for fixing and disclosing this issue. > > I'm sorry I'm not familiar with open-vm-tools, but I thought we could > clarify the below for everyone in here: > > On Mon, May 12, 2025 at 06:57:46PM +0530, VMware PSIRT wrote: > > A malicious actor with non-administrative privileges on a guest VM may > > tamper the local files to trigger insecure file operations within that VM. > > > https://github.com/vmware/open-vm-tools/tree/CVE-2025-22247.patch > > The commit message says: > > > Prevent usage of illegal characters in user names and file paths. > > Also, disallow unexpected symlinks in file paths. > > Skimming the code changes, I see that the second part - "disallow > unexpected symlinks in file paths" - is implemented by calling > realpath() (or a Windows function on that platform) and seeing whether > that changed the pathname or (almost) not. However, this will not > disallow a symlink that appears after the realpath() call but before > subsequent use of the pathname. > > Is a race condition like this relevant, or is it irrelevant given the > way these tools are normally used? In other words, is the filesystem > static when this code runs, or is it a live VM where "a malicious actor > with non-administrative privileges" may operate concurrently with this > code running? > > Can you please clarify? > > Thanks again, > > Alexander
