archive/zip: error reading large files from zip64 files #7069
Labels
Milestone
Comments
https://golang.org/cl/48150043 Status changed to Started. |
|
This issue was closed by revision 02a15e7. Status changed to Fixed. |
Here's a suitable replacement for archive/zip/testdata/zip64.zip that causes the archive/zip tests to fail before fe0a21b4dd1d but not after. By the way, I have anecdotal evidence that there exist zips with only an 8-bit zip64 header (i.e. one with the uncompressed file size but not the compressed file size or file offset), contrary to the note in the file-format description quoted above. However I can't share the instance I have, and haven't been able to create another one with this property. The fix that's in place now will still work, so this is just an academic point for posterity. Attachments:
|
|
This issue was updated by revision e7c2170. R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/49180043 |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I received a private bug report from a user who doesn't want to create an account to file a bug here. Unfortunately, the bug report has no repro case. In summary: in readDirectoryHeader, we can read too far into a zip64 Extra block. The Extra block is a repeated list of (extra tag + size + extra bytes of declared size). When we see the extra tag of 1 (zip64ExtraId), we then parse the extra block assuming the buffer is everything remaining in the file, instead of capping it at the declared size. That matters, because the Extra field is a variably-sized structure: Value Size Description ----- ---- ----------- (ZIP64) 0x0001 2 bytes Tag for this "extra" block type Size 2 bytes Size of this "extra" block Original Size 8 bytes Original uncompressed file size Compressed Size 8 bytes Size of compressed data Relative Header Offset 8 bytes Offset of local header record Disk Start Number 4 bytes Number of the disk on which this file starts This entry in the Local header MUST include BOTH original and compressed file size fields. If encrypting the central directory and bit 13 of the general purpose bit flag is set indicating masking, the value stored in the Local Header for the original file size will be zero.The text was updated successfully, but these errors were encountered: