minizip.pc.in would add @include@/minizip to the include path,
which would permit simply #include <zip.h> to use minizip. However
that conflicts with the zip.h from libzip that is put in the root
include directory. This now does not add /minizip to the include
path. Now when using pkg-config, #include <minizip/zip.h> must be
used, where #include <zip.h> would be used for libzip. This is an
incompatible change with the previous state. Users of minizip and
pkg-config will need to update their code. #include <unzip.h> will
need to be updated to #include <minizip/unzip.h> as well.
Not all toolchains on UNIX-style operating systems predefine
"unix". For example, it's missing on NetBSD, OpenBSD/gcc, AIX,
HP-UX. There is no single macro defined everywhere, but checking
both "__unix__" and "__unix" should cover everything except macOS,
which is already checked for using "__APPLE__".
Note that case sensitivity should default to off on macOS and
cygwin, so the check there is different.
Archive formats such as .zip files are generally susceptible to
so-called "traversal attacks". This allows an attacker to craft
an archive that writes to unexpected locations of the file system
(e.g., /etc/shadow) if an unspecting root user were to unpack a
malicious archive.
This patch neutralizes absolute paths such as /tmp/moo and deeply
relative paths such as dummy/../../../../../../../../../../tmp/moo
The Debian project requested CVE-2014-9485 be allocated for the
first identified weakness. The fix was incomplete, resulting in a
revised patch applied here. Since there wasn't an updated version
released by Debian with the incomplete fix, I suggest we use this
CVE to identify both issues.
Link: https://security.snyk.io/research/zip-slip-vulnerability
Link: https://bugs.debian.org/774321
Link: https://bugs.debian.org/776831
Link: https://nvd.nist.gov/vuln/detail/CVE-2014-9485
Reported-by: Jakub Wilk <jwilk@debian.org>
Fixed-by: Michael Gilbert <mgilbert@debian.org>
The appnote says that if the number of entries in the end record
is 0xffff, then the actual number of entries will be found in the
Zip64 end record. Therefore if the number of entries is equal to
0xffff, it can't be in the end record by itself, since that is an
instruction to get the number from the Zip64 end record. This code
would just store 0xffff in the end record in that case, not making
a Zip64 end record. This commit fixes that.
This checks the lengths of the file name, extra field, and comment
that would be put in the zip headers, and rejects them if they are
too long. They are each limited to 65535 bytes in length by the zip
format. This also avoids possible buffer overflows if the provided
fields are too long.
