Bug 1174844 (CVE-2014-8139)
| Summary: | CVE-2014-8139 unzip: CRC32 verification heap-based buffer overread (oCERT-2014-011) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Tomas Hoger <thoger> | ||||||||||
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Frantisek Sumsal <fsumsal> | ||||||||||
| Severity: | low | Docs Contact: | |||||||||||
| Priority: | low | ||||||||||||
| Version: | unspecified | CC: | andrewjcg, carnil, chenders, dsulliva, fsumsal, jaeshin, jrusnack, pstodulk, raysatiro, rskvaril, security-response-team, thoger, thomas.jarosch, yozone | ||||||||||
| Target Milestone: | --- | Keywords: | Security | ||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: |
A buffer overflow flaw was found in the way unzip computed the CRC32 checksum of certain extra fields of a file. A specially crafted Zip archive could cause unzip to crash when the archive was tested with unzip's '-t' option.
|
Story Points: | --- | ||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2015-03-18 21:11:14 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: | 1191118, 1196120, 1196121, 1196122, 1196123 | ||||||||||||
| Bug Blocks: | 1174865 | ||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 969598 [details] Upstream patch Upstream fix, as described in comment 0. Created attachment 971984 [details]
patch for fedora
Original patch has wrong metadadata - '--- extract.c;-1'. Corrected file with and added paths suitable for our package on Fedora/RHEL.
External Reference: http://www.ocert.org/advisories/ocert-2014-011.html Sorry if I'm mistaken, but I think this patch is causing "unzip -t" to now fail on executable JARs, which added the additional executable-jar extra field (http://stackoverflow.com/tags/executable-jar/info). With this patch, extra fields that list a length of zero fail: $ touch foo $ jar cvf foo.jar foo $ unzip -t foo.jar Archive: foo.jar testing: META-INF/ bad extra-field entry: EF block length (0 bytes) invalid (< 4) testing: META-INF/MANIFEST.MF OK testing: foo OK At least one error was detected in foo.jar. Looking at the patch, it seems wrong since I *think* the spec allows this (but I wasn't sure of this). (In reply to Andrew Gallagher from comment #6) > Sorry if I'm mistaken, but I think this patch is causing "unzip -t" to now > fail on executable JARs, which added the additional executable-jar extra > field (http://stackoverflow.com/tags/executable-jar/info). Upstream report of the issue is: http://www.info-zip.org/phpBB3/viewtopic.php?f=7&t=454 Upstream acknowledged that the patch was incorrect and changed it to only perform the underflow check for the affected extra field type. I will attach updated patch version, based on the extract.c version linked from the upstream forum. Created attachment 989833 [details]
Corrected upstream patch
The original report suggests code execution impact, but that does not seem to be correct. As reported, there is and integer underflow triggered by extra field of type EF_PKVMS and with length value less than 4 (i.e. 0-3). This leads to crc32() function called with length argument close to 2^32 (regardless of the system architecture), and leads to buffer over-read. This over-read is long - it will trigger crash on 32bit systems, and is likely to trigger crash on 64bit systems as well. As values read from the buffer are used to compute CRC value and are not copied to some other buffer, this does not corrupt memory, and hence does not have code execution impact. Affected code is only reached when running unzip in the test mode (unzip -t), but not when extracting zip archives. Created unzip tracking bugs for this issue: Affects: fedora-all [bug 1191118] Created attachment 990132 [details]
last corrected upstream patch
This is upstream patch which is part of last devel version. There are aesthetic (more readable) changes.
unzip-6.0-20.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. unzip-6.0-17.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. Statement: Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Low security impact and is not currently planned to be addressed in future updates in Red Hat Enterprise Linux 5. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/ Hi Tomas, Can you be more specific on comment #11? I'm assuming by crash you mean userspace unzip crash and not system crash. I'm fairly certain that is what you are inferring but figured I'd ask anyway. Thanks, Dave This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Via RHSA-2015:0700 https://rhn.redhat.com/errata/RHSA-2015-0700.html |
oCERT reports unzip flaw discovered by Michele Spagnuolo, Google Security Team. """ I would like to report a heap overflow condition in the CRC32 verification of unzip, which may result in arbitrary code execution. It can be triggered by passing a maliciously crafted zip files to unzip -t (version 6.00, both InfoZip and Debian). Patches: The problem was an unrealistic/invalid value in a .ZIP Extra Field. There was a check (in extract.c:TestExtraField()) for an extra-block length that was too large, but no check for a too-small value. In this example, the length (ebLen) was 1, and when "(ebLen-4)" was passed to crc32(), bad things happened. A revised extract.c (which adds a new check and error message) should be available here: http://antinode.info/ftp/unzip60/extract.c """ Acknowledgement: Red Hat would like to thank oCERT for reporting these issues. oCERT acknowledges Michele Spagnuolo of the Google Security Team as the original reporter.