Created attachment 386782 [details] Buggy zip file Description of problem: Running unzip on an invalid/corrupted .zip archive can trigger valgrind warnings about reading uninitialized values. This may indicate a bug in 'unzip'. Version-Release number of selected component (if applicable): unzip-5.52-12.fc12.x86_64 valgrind-3.5.0-9.x86_64 How reproducible: 100% Steps to Reproduce: 1. See attached file bug1.zip, bug2.zip, or bug3.zip 2. Run valgrind -q --leak-check=no unzip -o bug1.zip (or bug2.zip, or bug3.zip) Actual results: Valgrind warnings -- see attached files Expected results: No Valgrind warnings Additional info: I tried downloading the debuginfo for the unzip package, in hopes that this would lead to better Valgrind warning messages. However it appears that on my system Valgrind is broken: once I installed the debuginfo packages, Valgrind started giving my assertion failure errors associated with readelf.c, so I had to delete the debuginfo packages.
Created attachment 386783 [details] Buggy zip file
Created attachment 386784 [details] Buggy zip file
Created attachment 386785 [details] Valgrind warnings for bug1.zip
Created attachment 386786 [details] Valgrind warnings for bug2.zip
Created attachment 386787 [details] Valgrind warnings for bug3.zip
Can you report your findings directly to the upstream, please? http://www.info-zip.org/board/board.pl?b-unzipbugs/ This needs more work, as Valgrind warnings are often false positives. It would be great if you can discover actual flaws in the source code.
OK, I've reported this upstream. Thanks for the suggestion. Unfortunately I'm not able to diagnose this further, as I'm not familiar enough with the unzip source code; my apologies.
I have reported this upstream but it doesn't look like any action is likely; they say that unzip 5.52 (the latest version of unzip in Fedora 12) is about five years old.
If no actual flaws in the source code are found, this cannot be fixed. Please reopen this if you find a bug of the source code related to the Valgrind warnings.
The flaw in the source code is described in my bug report to upstream. See here: http://www.info-zip.org/board/board.pl?m-1267389382/ (scroll down to see the bug in the source code of do_string()) My upstream bug report does not appear to have led to any action from the upstream team, presumably because they are focused on unzip 6.0. I see this bugzilla entry was closed as NOTABUG. I'm reopening this, as in my view it is still a bug even if it will not be fixed. I assume you'll close it as WONTFIX if it will be left unfixed.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Quote from upstream channel: > Could be a potential bug. Probably should verify all the data was read. > However, this is in theory being read from the middle of the file, so > something regarding the file probably has to change in the middle > of reading data, which probably is not likely for a static file sitting > on the file system. Added a note to the TODO list to check this. Moving to rawhide, as this is still somehow valid in unzip 6.0. I agree with the upstream comment - this is an extreme case which most likely can't happen in normal use. Assigning low priority and low severity. I'll check the source code and upstream TODO list in next weeks.
Thanks, Vojtech. I appreciate it. (In reply to comment #13) > I agree with the upstream comment - this is an extreme case which most likely > can't happen in normal use. Here's the kind of scenario I was concerned about. A common use is to download a .zip file off the Internet (or save it from an attachment to an email) and unzip it using the "unzip" command. If that .zip file comes from an attacker, it would presumably be possible for an attacker to maliciously construct the .zip file in a way that triggers this bug, and (speculation:) possibly in a way that causes some harmful side-effect, akin to a buffer overrun. This is highly speculative. On the one hand, I can't rule out the possibility of a security risk. I have seen other cases where Valgrind warnings about use of uninitialized values indicated exploitable security vulnerabilities. On the other hand, I have not constructed such an exploit, and I would not place a very high likelihood on the chances that this particular bug can be exploited in such a way. My sense is that Valgrind warnings about uninitialized values indicate a security vulnerability only in a small fraction of cases (as a wild guess, 10-20%?). That fraction seems high enough that it probably justifies fixing or investigating the bug, but not high enough for me to get overly worried at this point. I don't think this changes your plan of action; I'm just sharing the reason why I reported it.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Created attachment 957278 [details] patch This could be solution for valgrind warnings. But it seems that this dangerous bug. I will discuss this with upstream again - it seems that this bug has forgotten due to more important bugs.
Corr: It seems that this is not dangerous bug. Patch was applied in upstream development version.
unzip-6.0-17.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/unzip-6.0-17.fc21
unzip-6.0-14.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/unzip-6.0-14.fc20
unzip-6.0-13.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/unzip-6.0-13.fc19
Package unzip-6.0-17.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing unzip-6.0-17.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15892/unzip-6.0-17.fc21 then log in and leave karma (feedback).
unzip-6.0-14.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
unzip-6.0-17.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.