jim-easterbrook / python-gphoto2

Python interface to libgphoto2
GNU Lesser General Public License v3.0
357 stars 59 forks source link

Vulnerable shared libraries might make gphoto2 vulnerable. Can you help upgrade to patch versions? #139

Closed JoeGardner000 closed 2 years ago

JoeGardner000 commented 2 years ago

Hi, @jim-easterbrook , @sdaau , I'd like to report a vulnerability issue in gphoto2_2.3.3.

Issue Description

gphoto2_2.3.3 directly or transitively depends on 50 C libraries (.so). However, I noticed that some C libraries are vulnerable, containing the following CVEs: libexif-8d1b563f.so.12.3.3 from C project libexif(version:0.6.21) exposed 7 vulnerabilities: CVE-2016-6328, CVE-2020-12767, CVE-2020-13112, CVE-2020-13113, CVE-2020-13114,CVE-2018-20030, CVE-2017-7544 libpng12-640ca796.so.0.49.0 from C project libpng(version:1.2.54) exposed 10 vulnerabilities: CVE-2011-3045, CVE-2014-9495, CVE-2013-7354, CVE-2013-7353,CVE-2017-12652, CVE-2015-8472, CVE-2016-10087, CVE-2016-3751, CVE-2015-0973, CVE-2015-8540 libXpm-99013f46.so.4.11.0 from C project libxpm(version:3.5.10) exposed 1 vulnerabilities: CVE-2016-10164

Furthermore, the vulnerable methods in the vulnerable shared libraries can be actually invoked by Python code. For instance, following call chains can reach the vulnerable method(C code) png_inflate() in file libpng/pngrutil.c reported by CVE-2011-3045.

call chains-----
readpng2_decode_data()->png_process_data()->png_process_some_data()->png_push_read_chunk()->png_handle_iCCP()->png_decompress_chunk()->png_inflate()

Suggested Vulnerability Patch Versions

libexif has fixed the vulnerabilities in versions >=0.6.23 libpng has fixed the vulnerabilities in versions >=1.6.32 libxpm has fixed the vulnerabilities in versions >=3.5.12

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

Thanks for your help~ Best regards, Joe Gardner

jim-easterbrook commented 2 years ago

Anyone concerned about these vulnerabilities could build python-gphoto2 from source, using their known good versions of libexif etc. The "binary wheels" are built with GitHub Actions - I don't think I can specify what versions of these libraries are installed on the build machines.

jim-easterbrook commented 2 years ago

See also https://github.com/pypa/manylinux/issues/1302

I don't plan to do anything about this. The risks are minimal in any usage of python-gphoto2 I can think of. If you have a usage where the risks might be significant, then you can use pip's --no-binary option to force building with your locally installed patched versions of the affected libraries.

If CentOS 7 (the OS used to build manylinux wheels) gets patched libraries then the next release of python-gphoto2 will have the patches.