New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ZipFile doesn't range check in _EndRecData() #49094
Comments
If you have a .zip file with an incomplete "End of Central Directory" D:\c64workdir\Ultimate_Mag_Archive>e:ziptest.py "old -
Ultimate_Mag_Archive"
Handling A-z\0\64times01-double.zip
Traceback (most recent call last):
File "E:\wwwroot\c64db\tools\ziptest.py", line 48, in <module>
ok = handle_file(data, rel_filename)
File "E:\wwwroot\c64db\tools\ziptest.py", line 19, in handle_file
z = zipfile.ZipFile(cStringIO.StringIO(data), "r")
File "C:\Python26\lib\zipfile.py", line 698, in __init__
self._GetContents()
File "C:\Python26\lib\zipfile.py", line 718, in _GetContents
self._RealGetContents()
File "C:\Python26\lib\zipfile.py", line 728, in _RealGetContents
endrec = _EndRecData(fp)
File "C:\Python26\lib\zipfile.py", line 219, in _EndRecData
endrec = list(struct.unpack(structEndArchive, recData))
struct.error: unpack requires a string argument of length 22 The fix is to include a check to see if there is data enough for the |
please attach 64times01-double.zip if possible |
Here is the file. Note that this can be reproduced with any zip file if |
I wrote a test for this and tried out the patch on the Python3 trunk, and it seems to work ok. I've attached an updated patch that includes the test. It probably wouldn't hurt to go look for other places where a struct is being unpacked without checking lengths first, and see if it makes sense to add a similar check in those places, too. I may do that later if I have some more free time. |
Following EAFP principle, it would be better - cleaner and more efficient - to put the stuct.unpack inside a try/except clause than checking the lengths beforehand. |
I had to look up the abbreviation (Easier to Ask Forgiveness than Permission), but that does sound like a good idea. Thanks for mentioning it. :-) |
Here is a patch for 3.4, which adds checks for other unpacks (except one, for which bpo-14315 exists). Also BadZipfile replaced by BadZipFile and trailing whitespaces deleted. For 2.7 BadZipFile should be replaced by BadZipfile back. |
In test_damaged_zipfile: + for N in range(len(s) - 2): why not |
I just copy it from Alan's test. Actually this is not needed, |
Patch updated. Now the test use io.BytesIO() for input too. A loop limit changed from len() -2 to len(). If there are no objections I'll commit this patch next week. |
New changeset 32de35f0f877 by Serhiy Storchaka in branch '2.7': New changeset 01147e468c8c by Serhiy Storchaka in branch '3.2': New changeset 46f24a18a4ab by Serhiy Storchaka in branch '3.3': New changeset e406b8bd7b38 by Serhiy Storchaka in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: