Bug 450597

Created attachment 146961 [details]
A zip file that karchive cannot read

SUMMARY
Kzip in karchive does not correctly handle zip files with data descriptors (ones where file headers do not include the lengths and CRCs, but they must be read from the data descriptor after the file contents).


STEPS TO REPRODUCE
1. Download test.zip file from attachments
2. Try to open the zip in Dolphin, or run `kziptest list test.zip`

OBSERVED RESULT
Reading the zip file will not succeed

EXPECTED RESULT
Opening the file in Dolphin should work

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kubuntu 21.10
(available in About System)
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.91.0 (karchive compiled from sources) 
Qt Version: 5.15.2

ADDITIONAL INFORMATION

I stumbled into this when trying to open a zip generated by Google Drive in Dolphin. Trying to open the zip resulted in this error: "Could not open the file, probably due to an unsupported file format." Ark and other tools that I tried opened the zip just fine.

My problematic zip included multiple epub files that are zips themselves. This seems to confuse karchive. Running `kziptest list` on this file prints the following: "Invalid ZIP file. Unrecognized header at offset 22988782". Right before that offset in my file there's a data descriptor block from _inside_ an epub file in the zip. 

When parsing a zip, after a file header, karchive seeks to the next data descriptor magic value after it. This is incorrect, because the compressed file contents may include the magic value. This apparently can happen with nested zips, and likely others, too. A zip can be altered to trigger this issue (that breaks CRCs, but other tools will still read the file):

$ head -c 1000 /dev/random | zip -fd -fz- test.zip -
$ printf 'PK\x07\x08' | dd of=test.zip seek=300 bs=1 count=4 conv=notrunc
$ unzip -v test.zip                                             
Archive:  test.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
    1000  Defl:N     1005  -1% 2022-02-19 19:17 edfd80a2  -
--------          -------  ---                            -------
    1000             1005  -1%                            1 file

$ ./kziptest list test.zip
Could not open "test.zip" for reading. ZIP file doesn't exist or is invalid: "Invalid ZIP file. Unrecognized header at offset 316"


Other similar files do not cause errors but can cause incorrect decompression results:

$ echo "aaaa" > a; echo "bbbb" > b; echo "cccc" > c
$ zip -fd -fz- inner.zip a b c
  adding: a (deflated -39%)
  adding: b (deflated -39%)
  adding: c (deflated -39%)
$ zip -fd -fz- -0 outer.zip inner.zip
  adding: inner.zip (stored 0%)
$ unzip -v outer.zip 
Archive:  outer.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
     481  Stored      481   0% 2022-02-20 06:40 72170cd6  inner.zip
--------          -------  ---                            -------
     481              481   0%                            1 file

$ ./kziptest list outer.zip 
mode=0100664 luryus luryus "c" size: 5 pos: 223 isdir=0
mode=0100664 luryus luryus "a" size: 5 pos: 31 isdir=0
mode=0100664 luryus luryus "b" size: 5 pos: 141 isdir=0
$ ./kziptest print-all foo/outer.zip
Opening zip file
Listing toplevel of zip file
Printing "b"
SIZE=0
DATA=
Printing "c"
SIZE=0
DATA=
Printing "a"
SIZE=0
DATA=

Here Kzip incorrectly jumps to read the inner zip contents while reading the outer file. Even then it cannot correctly read the files inside the inner zip (this can be seen in the `print-all` output).


Wikipedia's ZIP file page (https://en.wikipedia.org/wiki/ZIP_(file_format)#Structure) has this notion about parsing the files:
"Tools that correctly read ZIP archives must scan for the end of central directory record signature, and then, as appropriate, the other, indicated, central directory records. They must not scan for entries from the top of the ZIP file, because (as previously mentioned in this section) only the central directory specifies where a file chunk starts and that it has not been deleted. Scanning could lead to false positives, as the format does not forbid other data to be between chunks, nor file data streams from containing such signatures."

Karchive seems use the bad method, resulting in this issue.