How do we upgrade library versions in manylinux build? Avoiding potential security vulnerability...

[thomaslima]

Hello everyone,

One of the users of the klayout package has reported a (potential) security vulnerability in our manylinux wheels. I believe it is stemming from the curl library dependencies in the manylinux Docker image.

During the build, we just download curl-devel with yum, like so; yum install -y curl-devel. Is there something you recommend us to do? I am forwarding his report below.

https://github.com/KLayout/klayout/issues/1046

Thanks Thomas

I'd like to report a vulnerability issue in klayout_0.27.8.

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), klayout_0.27.8 directly or transitively depends on 41 C libraries (.so). However, I noticed that some C libraries are vulnerable, containing the following CVEs: libgssapi_krb5-497db0c6.so.2.2 libk5crypto-b1f99d5c.so.3.1 libkrb5-fc820a1d.so.3.3 libkrb5support-04204f6a.so.0.1 from C project krb5(version:1.16) exposed 2 vulnerabilities: CVE-2021-37750, CVE-2021-36222 libidn-97d26f25.so.11.6.11 from C project libidn(version:1.28) exposed 3 vulnerabilities: CVE-2015-8948, CVE-2016-6261, CVE-2016-6262

Suggested Vulnerability Patch Versions

krb5 has fixed the vulnerabilities in versions >=1.19.3 libidn has fixed the vulnerabilities in versions >=1.33

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

Thanks for your help~ Best regards, Andy

[mayeut]

Hello @thomaslima,

First, I'm no security expert so the following is just my 2 cents.

As mentioned in the KLayout issue, if relying on system packages, in the end, those issues should be covered by CentOS 7.

1. If a fix exists for CentOS 7, then, manylinux images will pick it up (there's at least 1 build a week to pick up upstream updates) so in the end, it comes down to: when was the fix published ? was the wheel built with that fix ? Please note that the original package version will probably not change and only the distro specific version will be updated.
2. A fix does not exist in the upstream image, then, I guess you'll have to do an impact analysis to check wether or not the potential security vulnerability is applicable in your use-case and decide what to do for your use-case. The only possible solutions if you need to upgrade are to get RedHat to publish a fix (check https://access.redhat.com/security/security-updates/#/cve, they've probably already decided not to fix it for a specific reason) or rebuild what you need from sources.

Out of the 5 CVE listed, only one has been fixed by RedHat on RHEL/CentOS 7: CVE-2021-37750 The other one for krb5 has been marked "out of support scope": cve-2021-36222

The ones for libidn are all marked "low impact, Will not fix".

[mayeut]

Another option not mentioned in the previous comment would be to update from manylinux2014 to manylinux_2_24 or the upcoming manylinux_2_28 (if they're not impacted). This would come with its own caveats, you won't be able to reach all your users with such wheels (glibc versions, pip version) who will start to see rebuilds from source happening (or you'll need to build different wheels for those users => back to the original question).