CVE-2023-45853 - zlib.dll is installed as a dependency for h5py

[siabingtao]

• Operating System: Windows 10
• Python version 3.10.11
• h5py version (e.g. 3.7.0)
• hdf5 version (e.g. 1.12.2)

Hi all, is there any fix for CVE-2023-45853 as zlib.dll is installed as dependency when h5py is installed?

[aragilar]

I've not looked at how this differs from the last zlib CVE (see #2254 for h5py-specific discussion), but the important question is does this affect HDF5, if not you can ignore it, else the best thing you can do for now is build from source (i.e. do not use the pre-built wheels on PyPI) using a fixed zlib and hence HDF5 as mentioned in the previous issue (it's probably easiest to use the appropriate package manager for your OS to do this).

[aragilar]

Based on https://nvd.nist.gov/vuln/detail/CVE-2023-45853 and https://bugs.chromium.org/p/chromium/issues/detail?id=1470539, the problem is with zipOpenNewFileInZip4_64, which HDF5 appears not to use (based on a search: https://github.com/search?q=repo%3AHDFGroup%2Fhdf5+zipOpenNewFileInZip4_64&type=code).

[landon-kanner]

What about
CVE-2018-25032 ?

[tacaswell]

@landon-kanner can you show that is used by hdf5?

[landon-kanner]

@landon-kanner can you show that is used by hdf5?

Show what is used by hdf5? zilb? I don't know, but if it is not, why is it included?

[tacaswell]

I mean the relevant function for that CVE.

[landon-kanner]

The CVE does not list a specific function:

zlib before 1.2.12 allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches.

[tacaswell]

madler/zlib@5c44459 is the fix so it is possible to sort out if this is ever used by libhdf5.

If it is, then we should pull down the wheels (and I think it is an open question of if we should try to rebuild them). If it is not then I think the convenience of having wheels out weighs the risk (but am open to being convinced I am wrong).

---

Given that wheels do not carry enough meta-data to ask what versions of dependencies they vendor (and because they vendor all of there dependencies!), I suggest using alternate packing ecosystems (e.g. conda, any linux package manager) if you need to be sure that the binary artifacts of versions of transient dependencies are not installed on your systems.

[takluyver]

On Linux we don't bundle zlib at all - we rely on it being present on the system, so it's not up to us to update it.

On Mac it's bundled at version 1.2.13, which is not affected by that CVE-2018-25032 ("before 1.2.12"). You can see this here:

h5py/ci/configure_hdf5_mac.sh

Line 12 in 4c01efa

ZLIB_VERSION="1.2.13"

On Windows an older version is bundled, so it may be vulnerable, if it's possible to trigger that CVE through HDF5. We really need someone who knows about Windows build stuff to step up and fix that - see #2261. My use of h5py at work is entirely on Linux, and I suspect the other core maintainers are in similar situations, so the unfortunate reality is that we can't support Windows so well. If no-one steps forward to tackle it, maybe we'll have to stop publishing pre-built Windows packages and push those users towards conda or some other solution which can deal with this better.

[aragilar]

Given zlib is distributed with CPython, I wonder if there's some way to point at that version? I'm not familiar enough with how Windows does its linking, but presumably it can only load one version of zlib into memory at once?

[takluyver]

I don't know. Maybe it's statically linked into Python on Windows?

If there's a way to avoid bundling it on any platform, that would certainly be nice.