Source: zlib Followup-For: Bug #1054290 X-Debbugs-Cc: david.dooling+deb...@docker.com, car...@debian.org, Debian Security Team <t...@security.debian.org>
On Tue, 31 Oct 2023 13:13:00 -0500, David wrote: > Thanks for that analysis, James. ... > nodejs-18.13.0+dfsg1: > The Node.js source code includes a copy of the zlib source code. This > copy was patched over a month ago. Thanks David for the follow-up! I had indeed missed that nodejs is already patched; great -- and that also demonstrates that I hadn't checked whether each callsite I found was using a locally-vendored copy of the minizip code (that's the situation you mention where packages clone zlib into their own code). As context: Debian's preferred approach[1] is that each package de-duplicates references to library code that is already packaged in Debian -- even if the originating codebase simply includes a copy of it -- because when a security issue like this appears, it's easier if there's only a single place to patch. > After checking two common packages and seeing the same, someone > nonstandard pattern, I downloaded and compiled zlib myself. By > default, it does not appear that any of the minizip functions are > included in any header file or library installed as part of the normal > zlib './configure && make && make install'. So perhaps all these > usages of these functions are associated with downstream software > closing zlib source into their code? If that is the case, what does > that mean for this CVE and actually creating a coherent response > across all these packages? About the default compile options for zlib: that's correct: minizip is a non-core part of the zlib codebase, referred to as a 'contrib'[2], often implying a lower maintenance guarantee. Debian does provide a package called 'minizip' that builds binaries from the relevant code, though. About what to do regarding the other packages: After removing nodejs, and checking each remaining package's source, I find that only 11 (eleven) of the packages in fact contain a full copy of minizip with the vulnerable section of code. A few packages referenced 'quazip' - a fork of minizip. Of those, only 1 (one) appears to support 64-bit zip files, and it does look like it has the vulnerability too. For 3 (three) of the remaining packages, I'm uncertain whether copied code that looks like older versions minizip is in fact vulnerable; those are the 'magics++' and 'widelands' packages, where 64-bit zip support appears incomplete or missing, and 'gdal', where the code appears to be part of a library called 'CPL' that may have shared some lineage with minizip. In the latter case, I'll ask the CPL maintainers whether they think it's affected on their mailing list[3]. The twelve (11 minizip + 1 quazip) vendored code locations are: https://sources.debian.org/src/gmsh/4.8.4+ds2-3/contrib/zipper/zip.c/?hl=1055#L1085 https://sources.debian.org/src/godot/3.5.2-stable-2/thirdparty/minizip/zip.c/?hl=1292#L1088 https://sources.debian.org/src/httrack/3.49.4-1/src/minizip/zip.c/?hl=1311#L1086 https://sources.debian.org/src/libxlsxwriter/1.1.5-1/third_party/minizip/zip.c/?hl=1057#L1088 https://sources.debian.org/src/mariadb/1:10.11.5-3/storage/connect/zip.c/?hl=1337#L1086 https://sources.debian.org/src/mupen64plus-core/2.5.9+341+gf82b37bf-1/subprojects/minizip/zip.c/?hl=1265#L1086 https://sources.debian.org/src/orthanc/1.12.1+dfsg-4/OrthancFramework/Resources/ThirdParty/minizip/zip.c/?hl=1337#L1086 https://sources.debian.org/src/qt6-webengine/6.4.2-final+dfsg-12/src/3rdparty/chromium/third_party/zlib/contrib/minizip/zip.c/?hl=1273#L1086 https://sources.debian.org/src/qtwebengine-opensource-src/5.15.15+dfsg-2/src/3rdparty/chromium/third_party/zlib/contrib/minizip/zip.c/?hl=1288#L1086 https://sources.debian.org/src/rbdoom3bfg/1.4.0+dfsg-2/neo/libs/zlib/minizip/zip.cpp/?hl=1307#L1112 https://sources.debian.org/src/swi-prolog/9.0.4+dfsg-2/src/minizip/zip.c/?hl=1065#L1096 https://sources.debian.org/src/tea/62.0.2-1/zip.c/?hl=1345#L1113 I'd like someone else to confirm with me whether this is a good idea or not, but my suggestion would be that we file a bug with each of the Debian source packages (src:gmsh for example), linking to the affected line and referencing this bug and the CVE to explain the problem. Then each package's maintainer could check whether they think their package is genuinely affected, and decide whether to patch the problem within Debian only, and/or to forward the fix to the code distributors (aka upstream), or to do nothing (which is a valid choice, especially if the code can't be reached from their package even if it's theoretically built into it). It's possible I'm overexplaining some of that, so my apologies if so - just trying to be clear. [1] - https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies [2] - https://github.com/madler/zlib/issues/868#issuecomment-1783525536 [3] - https://lists.osgeo.org/mailman/listinfo/gdal-dev
