Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
MikeWazoWski123 opened this issue Apr 2, 2022 · 7 comments

Comments

@MikeWazoWski123
Copy link

Hi, @jdavid , @carlosmn , I'd like to report a vulnerability issue in pygit2_1.9.1.

Dependency Graph between Python and Shared Libraries

image

Issue Description

As shown in the above dependency graph(here shows part of the dependency graph, which depends on vulnerable shared libraries), pygit2_1.9.1 directly or transitively depends on 15 C libraries (.so). However, I noticed that some C libraries are vulnerable, containing the following CVEs:
libcrypto-17bcacf6.so.1.0.2k and libssl-53a623ad.so.1.0.2k from C project openssl(version:1.0.2k) exposed 11 vulnerabilities:
CVE-2018-0732, CVE-2019-1559, CVE-2019-1547, CVE-2019-1563, CVE-2019-1551, CVE-2020-1971, CVE-2021-23841, CVE-2020-1968, CVE-2018-0734, CVE-2017-3736, CVE-2019-1552
libgssapi_krb5-497db0c6.so.2.2, libk5crypto-b1f99d5c.so.3.1 and libkrb5-fc820a1d.so.3.3 from C project krb5(version:1.16) exposed 2 vulnerabilities:
CVE-2021-37750,CVE-2021-36222

Suggested Vulnerability Patch Versions

openssl has fixed the vulnerabilities in versions >=1.1.1l
krb5 has fixed the vulnerabilities in versions >=1.19.3

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

Thanks for your help~
Best regards,
MikeWazowski

@jdavid
Copy link
Member

jdavid commented Apr 3, 2022

The version of openssl in the wheel is the one from Centos 7, which already has some security patches, specifically the latest release includes https://centos.pkgs.org/7/centos-updates-x86_64/openssl-1.0.2k-24.el7_9.x86_64.rpm.html

If this is not enough we could switch from manylinux2014 to manylinux_2_24 wheels, which is based on Debian 9 and has a more recent version of the libraries. This would however make it harder to install pygit2 wheels, since it would require a more recent version of pip.

@MikeWazoWski123
Copy link
Author

@jdavid, thanks for your help and feedback.

This would however make it harder to install pygit2 wheels, since it would require a more recent version of pip.

Compatibility or security? It is really hard to chose.
By the way, is the diagnosis information useful to you? I am happy to know that :)

Best regards,
MikeWazowski

@jdavid
Copy link
Member

jdavid commented Apr 4, 2022

Yes it's useful.

So there are some vulnerabilities not addressed by the Centos package, yet Centos 7 is still maintained, and the package maintainers decided not to patch those vulnerabilities. Upgrading to manylinux_2_24 should address some issues, but probably not all. For reference these are the versions in the latest pygit2 release:

  • openssl 1.0.2k-24.el7_9
  • krb5 1.15.1-51.el7_9

In Debian 9 we have:

  • openssl 1.1.0l-1~deb9u5
  • krb5 1.15-1+deb9u3

@4a6f656c
Copy link

@jdavid (cc @howbazaar) security issues from bundling a CentOS patched version of an EOL security library aside, this is also a regression from a functional perspective - there are numerous features and bug fixes that exist in OpenSSL 1.1.x that are not present in OpenSSL 1.0.2. This includes certificate chain verification fixes (#1115) and support for ed25519 (#1143). Bundling OpenSSL 1.0.2 is effectively taking the lowest common denominator and forcing it upon everyone who uses these wheels, even if they are being used on a modern system that has better functionality and security maintenance available.

@jdavid
Copy link
Member

jdavid commented Aug 24, 2022

Yes, OpenSSL should not be included in the wheels, and instead the system library should be used.
PRs welcome.

jdavid added a commit that referenced this issue Aug 28, 2022
@jdavid
Copy link
Member

jdavid commented Nov 10, 2022

The latest release v1.11.1 is based on manylinux 2_24 and includes openssl 1.1

@chet-manley
Copy link

Just an FYI, switching to manylinux_2_24 broke wheel compatibility with RHEL 7, which uses glibc 2.17. I now have to manually build openssl11, libssh2, libgit2, & pygit2 wheels in manylinux2014 to maintain pygit2 for our internal projects that are deployed to OEL7 hosts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants