On Fri, Jul 3, 2026 at 10:53 PM Imran Zaheer <[email protected]> wrote: > > Hi > > + strstr(relativeFilename, "..") != NULL || > > This will also reject a valid unix filename i.e. "blob..1.toc" which > are unrelated to path traversal. Should we care about such file names > here? > I think instead of strstr we can check direct string "." and ".." as changed in my patch.. > > > On Fri, Jul 3, 2026 at 8:07 PM Jonathan Gonzalez V. > <[email protected]> wrote: > > > > > > Hello!! > > > > Dilip Kumar <[email protected]> writes: > > > I would like to submit a patch to address a path traversal > > > vulnerability in pg_dump's directory format mode (-F d). Currently, > > > filenames listed in directory-format TOC files (toc.dat and > > > blobs_*.toc) are treated as trusted when reading an archive during a > > > restore. If an archive entry filename is maliciously modified to > > > contain path traversal elements (such as ..) or directory separators, > > > pg_restore can be tricked into reading files outside the intended > > > backup directory. The attached patch fixes this vulnerability. > > > > I was taking a look into the patch and, yes it works as expected, but I > > also manage to get the same result of a path traversal having a with a > > symlink as follow: > > > > blob_16388.dat -> ../../../../../../../etc/passwd > > > > Probably it could be worthy to add the symlink check with lstat() ?
Yeah that makes sense. I have fixed that. -- Regards, Dilip Kumar Google
v2-0001-pg_dump-Validate-archive-entry-filenames-in-direc.patch
Description: Binary data
