[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2e423790-d7f1-4873-a840-9af284c3576f@gmail.com>
Date: Thu, 25 Sep 2025 12:08:58 -0700
From: Matthew Fernandez <matthew.fernandez@...il.com>
To: oss-security@...ts.openwall.com, vmware.psirt@...adcom.com
Subject: Re: CVE-2025-22247 - Insecure file handling
vulnerability in open-vm-tools
On 9/24/25 23:38, VMware PSIRT wrote:
> Hi Alexander,
>
> We somehow missed your previous e-mail. Thank you for reviving this thread.
>
> Please see our responses below:
>
>> 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.
>
> Thanks you for raising this. You are right about realpath() and
> symlink usage in general. However, as you can see we are performing
> realpath() check after we completed the open() but before we read
> anything from the file. So, there is no use of pathname after realpath()
> call here.
Is this not now simply vulnerable to the opposite race?
1. Attacker creates unexpected symlink
2. open()
3. Attacker overwrites symlink with something benign
4. realpath(), sees nothing suspicious
You now have an open FD through the unexpected symlink without having
detected it.
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.
