Vulnerable shared libraries might make kivy vulnerable. Can you help upgrade to patch versions?

[andy201709]

Hi, @tito , @Zen-CODE , I'd like to report a vulnerability issue in kivy_2.1.0.

Dependency Graph between Python and Shared Libraries

Issue Description

As shown in the above dependency graph, kivy_2.1.0 directly or transitively depends on 22 C libraries (.so). However, I noticed that some C libraries are vulnerable, containing the following CVEs: libjpeg-43436dd5.so.62.1.0 from C project libjpeg-turbo(version:1.3.0) exposed 1 vulnerabilities: CVE-2018-14498 libtiff-b6eb22fb.so.5.2.0 from C project tiff(version:<=4.0.6) exposed 11 vulnerabilities: CVE-2020-35523 , CVE-2019-7663, CVE-2019-14973, CVE-2018-10963, CVE-2017-9935, CVE-2016-9537, CVE-2016-9538, CVE-2016-9534, CVE-2016-9536, CVE-2016-9540, CVE-2016-9535 libwebp-2877905a.so.4.0.2 from C project libwebp(version:<=0.4.0) exposed 11 vulnerabilities: CVE-2018-25009, CVE-2018-25014, CVE-2018-25013, CVE-2018-25012, CVE-2018-25011, CVE-2018-25010, CVE-2020-36331, CVE-2020-36330, CVE-2020-36328, CVE-2020-36329, CVE-2020-36332

Furthermore, the vulnerable methods in these vulnerable shared libraries can be actually invoked by Python code. For instance, the following C methods are actually invoked by python code in kivy, which declared in lib\sdl2.pxi:

...
cdef extern from "SDL_image.h":
    ...
    cdef int IMG_Init(IMG_InitFlags flags)
    cdef char *IMG_GetError()
    cdef SDL_Surface *IMG_Load(char *file)
    cdef SDL_Surface *IMG_Load_RW(SDL_RWops *src, int freesrc)
...

The following call chain starting from int IMG_Init(IMG_InitFlags flags) can reach the vulnerable methods:

• int gtTileContig (TIFFRGBAImage *img, uint32 *raster, uint32 w, uint32 h) in tif_getimage.c reported by CVE-2020-35523 :

call chain -----
IMG_Init() -> IMG_InitTIF() -> TIFFReadRGBAImage() -> TIFFReadRGBAImageOriented() -> TIFFRGBAImageBegin() -> PickContigCase() -> gtTileContig()

• int TIFFWriteDirectoryTagTransferfunction (TIFF *tif, uint32 *ndir, TIFFDirEntry *dir) in tif_dirwrite.c reported by CVE-2019-7663:

call chain -----
IMG_Init() -> IMG_InitTIF() -> TIFFClientOpen() -> TIFFCleanup() -> TIFFFlush() -> TIFFRewriteDirectory() -> TIFFWriteDirectory() -> TIFFWriteDirectorySec() -> TIFFWriteDirectoryTagTransferfunction()

• int gtStripSeparate (TIFFRGBAImage *img, uint32 *raster, uint32 w, uint32 h) in tif_getimage.c reported by CVE-2019-14973 :

call chain -----
IMG_Init() -> IMG_InitTIF() -> TIFFReadRGBAImage() -> TIFFReadRGBAImageOriented() -> TIFFRGBAImageBegin() -> PickSeparateCase() -> gtStripSeparate()

Suggested Vulnerability Patch Versions

libjpeg-turbo has fixed the vulnerabilities in versions >=2.0.0 tiff has fixed the vulnerabilities in versions >=4.1.0 libwebp has fixed the vulnerabilities in versions >=1.0.1

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

Thanks for your help~ Best regards, Andy

[matham]

We get these libraries automatically from the OS (centos 7) on which kivy is compiled and ourselves don't actually compile these so we can't really provide updated versions of these libraries if the OS hasn't updated them.

More importantly, I don't think this is part of our threat model. I think it's understood, especially for python packages, that only you are supposed to control what gets passed to these libraries. Meaning that since you're fully in control of the app you make and its inputs you shouldn't be in a position where you e.g. unknowingly can load a bad image that would cause these issues. But, if you make an app using Kivy that is distributed and your users could load random images and be exposed to an attack, then you should probably compile kivy yourself and ensure that it's updated as Kivy itself is not kept updated with any security issues, beyond yearly releases.

[andy201709]

Thank you very much for your kindly feedback. @matham

[leycec]

To corroborate @matham, the only security issue vis-a-vis Kivy would be if Kivy or subcomponents thereof (e.g., Buildozer, python-for-android) contained a narrow dependency on a maximum version of a vulnerable C library and all such versions were vulnerable. So, something like libtiff <= 4.0.6 in a setup.py installer or Buildozer recipe. That probably isn't the case; this can probably be safely closed.

It's also pertinent to note that @matham appears to be a Main Coon (source: have two Maine Coons) communicating with the feisty kitten that is @Andy201709. Joy is cat avatars on GitHub.

[Julian-O]

Closing as this seems to be out of Kivy's scope.

{I really appreciate the quality of this analysis though!]