Known vulnerabilities in shared libraries which urh depends on.Can you help upgrade to patch versions?

[andy201709]

Hi, @jopohl , @andynoack , I'd like to report a vulnerability issue in urh_2.9.3.

Dependency Graph between Python and Shared Libraries

Issue Description

As shown in the above dependency graph(here shows part of the dependency graph, which depends on vulnerable shared libraries), urh_2.9.3 directly or transitively depends on 42 C libraries (.so). However, I noticed that some C libraries are vulnerable, containing the following CVEs: libavahi-client-b9dcf138.so.3.2.9 libavahi-common-36709de0.so.3.5.3from C project avahi(version:0.6.31) exposed 3 vulnerabilities: CVE-2021-3468, CVE-2021-26720, CVE-2017-6519 libudev-9a7475a2.so.1.6.2 from C project systemd(version:<=229) exposed 24 vulnerabilities: CVE-2018-15686, CVE-2018-15688, CVE-2018-15687, CVE-2018-16866, CVE-2018-16865, CVE-2018-16864, CVE-2021-33910, CVE-2020-1712, CVE-2020-13776, CVE-2019-3843, CVE-2019-3844, CVE-2019-3842, CVE-2018-16888, CVE-2018-6954, CVE-2017-18078, CVE-2018-1049, CVE-2017-1000082, CVE-2017-9445, CVE-2016-7796, CVE-2016-7795, CVE-2017-9217, CVE-2013-4392, CVE-2019-20386, CVE-2017-15908 libxml2-3998bec4.so.2.9.1 from C project libxml2(version:2.9.1) exposed 44 vulnerabilities: CVE-2016-4658, CVE-2016-4483, CVE-2016-3627, CVE-2016-1839, CVE-2016-2073, CVE-2016-1838, CVE-2016-1840, CVE-2016-1836, CVE-2015-8242, CVE-2015-8035, CVE-2015-8806, CVE-2015-7500, CVE-2015-7499, CVE-2015-7498, CVE-2015-5312, CVE-2015-7497, CVE-2021-3541, CVE-2021-3537, CVE-2021-3518, CVE-2021-3517, CVE-2021-3516, CVE-2014-3660, CVE-2019-19956, CVE-2018-14404, CVE-2015-8710, CVE-2015-8317, CVE-2015-8241, CVE-2016-9596, CVE-2016-9598, CVE-2017-18258, CVE-2017-5130, CVE-2017-15412, CVE-2017-7375, CVE-2017-7376, CVE-2016-9318, CVE-2016-4448, CVE-2016-4449, CVE-2016-4447, CVE-2016-1834, CVE-2016-1833, CVE-2016-1837, CVE-2016-1762, CVE-2017-16931, CVE-2017-16932

Furthermore, the vulnerable methods in the vulnerable shared libraries can be actually invoked by Python code. For instance, the following call chain can reach the vulnerable method(C code) xmlNodePtr xmlStringGetNodeList (xmlDocPtr doc, const xmlChar *value)in tree.c reported by CVE-2016-3627 :

call chain -----
xmlInitParser() -> xmlDefaultSAXHandlerInit() -> xmlSAXVersion() -> xmlSAX2StartElementNs() -> xmlNewDocNodeEatName() -> xmlStringGetNodeList()

Suggested Vulnerability Patch Versions

avahi has fixed the vulnerabilities in versions >0.8（no patch） systemd has fixed the vulnerabilities in versions >=250 libxml2 has fixed the vulnerabilities in versions >=2.9.11

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

Thanks for your help~ Best regards, Andy

[jopohl]

Thanks for reporting. I assume you refer to the URH wheels? If so, are these vulnerabilities only present for Python 3.7 as shown in the dependency graph or are other versions affected as well?

Edit: Just checked it, affects higher Python versions as well. We build these wheels using quay.io/pypa/manylinux2014_x86_64 Docker container. A similar issue was already opened there: https://github.com/pypa/manylinux/issues/1302 - we would need to wait for an update before we rebuild.

[jopohl]

As suggested in this comment I updated to the manylinux_2_28 image to build the wheels so those vulnerabilities should be fixed. I will close this issue, if a subsequent scan should reveal that there are still vulnerabilities present feel free to reopen. Thank you for keeping URH safe.