Re: Path Traversal Vulnerability in pg_dump Directory Format
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Imran Zaheer <imran.zhir@gmail.com>
Cc: "Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, jchord@google.com,
dtighe@google.com
Date: 2026-07-04T13:33:25Z
Lists: pgsql-hackers
Attachments
- v2-0001-pg_dump-Validate-archive-entry-filenames-in-direc.patch (application/octet-stream) patch v2-0001
On Fri, Jul 3, 2026 at 10:53 PM Imran Zaheer <imran.zhir@gmail.com> 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. > <jonathan.abdiel@gmail.com> wrote: > > > > > > Hello!! > > > > Dilip Kumar <dilipbalaut@gmail.com> 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