[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250924023739.GA21012@openwall.com>
Date: Wed, 24 Sep 2025 04:37:39 +0200
From: Solar Designer <solar@...nwall.com>
To: VMware PSIRT <vmware.psirt@...adcom.com>
Cc: oss-security@...ts.openwall.com, John Wolfe <john.wolfe@...adcom.com>
Subject: Re: CVE-2025-22247 - Insecure file handling vulnerability in open-vm-tools
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
