go to bug id or search bugs for
This issue is somewhat similar to http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5658 but more limited: it only allows you to create new directories, not files.
Inside php_zip.c there's a function called php_zip_make_relative_path which is used to sanitize the file path when extracting a file/directory from a ZIP. When extracting a file the sanitized pathname is used, so files are only created inside of the directory where they're being extracted. However, for directories, the unsanitized/user-provided "file" value is used instead of the sanitized"path_cleaned" value (https://github.com/php/php-src/blob/026b41ba664bd8f76d6d201d7af8e70c8b650194/ext/zip/php_zip.c#L172-L176). As a result, a directory can be created outside of the directory where a ZIP file is being extracted.
Compared to CVE-2008-5658 this is a much more minor issue since it is limited to the creation of directories rather than files. This issue appears to have been previously reported as #67996 but was closed as not a bug.
$archive = new ZipArchive();
$archive2 = new ZipArchive();
A directory called down2 is created inside of .
A directory called down2 is created inside of the parent directory.
Add a Patch
Add a Pull Request
Proposed patch: https://gist.github.com/smalyshev/2d755c7016921437a806
Fixed in git.
Automatic comment on behalf of stas
Log: Fixed bug #70350: ZipArchive::extractTo allows for directory traversal when creating directories
From CVE assign response:
Use CVE-2014-9767 for this issue that was apparently disclosed in
https://bugs.php.net/bug.php?id=67996 in 2014. The issue could be
relevant in cases where, for example:
- a parent directory is on a filesystem that can't support many
inodes, and the attacker can cause a DoS by creating thousands of
empty directories there
- a parent directory is served by the web server and allows a full
directory listing, and the attacker can therefore post spam in the
form of directory names
I am confused as to why this really needs a CVE. Also, since CVE-2014-9767 seems to have no content since 2014, I wonder whether it is meaningful to assign it at all.
We can ask them to update the content. The trigger for the assignment was a similar fix by HHVM and then a CVE request by Debian.