Potential vulneraility in the C library which pyhdf depends on. Can you help upgrade to patch versions?

[mikewazowski123]

Hi, @fhs , @teoliphant, I'd like to report a vulnerability issue in pyhdf_0.10.3.

Dependency Graph between Python and Shared Libraries

Issue Description

As shown in the above dependency graph, pyhdf_0.10.3 directly or transitively depends on 2 C libraries (.so). However, I noticed that one C library is vulnerable, containing the following CVE:
libjpeg-43436dd5.so.62.1.0from C project libjpeg-turbo(version:1.3.0) exposed 2 vulnerabilities:
CVE-2020-14152, CVE-2018-14498

Furthermore, the vulnerable methods in these vulnerable shared libraries can be actually invoked by Python code.
For instance, the following call chain starting from jpeg_start_compress() can reach the vulnerable method GLOBAL(size_t) jpeg_mem_available (j_common_ptr cinfo, size_t min_bytes_needed, size_t max_bytes_needed, size_t already_allocated) in jmemnobs.c reported by CVE-2020-14152:

call chain -----
jpeg_start_compress() -> jinit_compress_master() -> realize_virt_arrays() -> jpeg_mem_available()

Suggested Vulnerability Patch Versions

libjpeg-turbo has fixed the vulnerabilities in versions >=2.0.0

Python build tools cannot report vulnerable C libraries, which may induce potential security issues to many downstream Python projects.
As a popular python package (ppyhdf has 4,576 downloads per month), could you please upgrade the above shared libraries to their patch versions?

Thanks for your help~
Best regards,
MikeWazowski

[Alan Brammer]

libjpeg-turbo-devel==1.2.90-8 is installed as a dependency from hdf and hdf-devel.
Adding the libjpeg-turbo-offcial repo and forcing a >=2x install doesn't resolve that dependency, and those 2 key libraries still want to install the old libjpeg.

The library originates from yum -y install epel-release hdf hdf-devel inside of container quay.io/pypa/manylinux2014_x86_64.

Can you provide guidance on how to update the library given the upstream dependencies.

[David Hoese]

I noticed this issue while looking up some compilation errors. I just wanted to say that if someone is encountering an old version of libjpeg bundled with the pyhdf binary wheel packages, a workaround is to provide --no-binary pyhdf to your pip command. For example pip install --no-binary pyhdf pyhdf. This should force pip to build from pyhdf source which should dynamically look for whatever version of HDF4 and libjpeg/libjpeg-turbo are available on the system.

As far as getting the corrected/fixed versions of these dependencies on your system, that's another discussion. If pyhdf's wheel building automatically finds these new versions of these dependencies next time it builds its wheels (a future release) then the wheels on PyPI will also be using those fixed versions (because they'll be bundled internally).