Bug 688735 (CVE-2011-0421)
| Summary: | CVE-2011-0421 php/libzip: segfault with FL_UNCHANGED on empty archive in zip_name_locate() | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | bressers, dave, fedora, fedora, jlieskov, jorton, redhat-bugzilla, rpm, vvitek |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-04-05 20:08:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 688940, 688941, 688942 | ||
| Bug Blocks: | |||
|
Description
Vincent Danen
2011-03-17 21:10:52 UTC
I don't believe this is something that would be exploitable under normal circumstances. For one, the only reference I can find to this FL_UNCHANGED flag is in ZipArchve::getNameIndex(): http://php.net/manual/en/function.ziparchive-getnameindex.php The reproducers noted in the bug use ZipArchive::locateName(), and FL_UNCHANGED is not a documented flag there: http://php.net/manual/en/function.ziparchive-locatename.php The reproducers are: PoC1: php -r '$nx=new ZipArchive();$nx->open("/dev/null");$nx->locateName("a",ZIPARCHIVE::FL_UNCHANGED);' PoC2: php -r '$nx=new ZipArchive();$nx->open("empty.zip");$nx->statName("a",ZIPARCHIVE::FL_UNCHANGED);' I have a hard time believing something like this would be a problem in normal use, and it can certainly be mitigated by making sure that the file is not 0 bytes (a sensible thing to test for on uploaded files anyways). For instance: % echo 1 >empty.zip % php -r '$nx=new ZipArchive();$nx->open("empty.zip");$nx->statName("a",ZIPARCHIVE::FL_UNCHANGED);' PHP Warning: ZipArchive::statName(): Invalid or unitialized Zip object in Command line code on line 2 This also would only affect Red Hat Enterprise Linux 6 and Fedora as earlier versions of PHP do not have this functionality. This also would affect libzip, mingw32-libzip, and openlierox (the latter contains an embedded libzip, although it is linked to the system libzip so probably does not require a patch). Not too much requires libzip, so this is probably just as "major" there as it is for PHP (abrt-plugin-filetransfer uses libzip, but I suspect to create zip files for uploading, ebook-tools/ebook-tools-libs and fuse-zip also require it; I suspect the problematic package there would be fuse-zip). I'm going to add trackers for libzip and mingw32-libzip. Created php tracking bugs for this issue Affects: fedora-all [bug 688940] Created libzip tracking bugs for this issue Affects: fedora-all [bug 688941] Created mingw32-libzip tracking bugs for this issue Affects: fedora-all [bug 688942] An additional link with further information: http://securityreason.com/achievement_securityalert/96 This issue did NOT affect the versions of the php package, as shipped with Red Hat Enterprise Linux 4 and 5. -- This issue affects the version of the php53 package, as shipped with Red Hat Enterprise Linux 5. This issue affects the version of the php package, as shipped with Red Hat Enterprise Linux 6. I'm closing this as WONTFIX. Nothing shipped in Red Hat Enterprise Linux uses this option. Google code search shows that almost no applications use it ever (the list if very small and obscure). Given this can only crash an application, we will not be fixing this bug as a security flaw. This was fixed in libzip 0.10 (see http://www.nih.at/libzip/NEWS.html). Fedora 17+ have this, Fedora 16 still ships 0.9. |