[Package Request] - High Vulnerable Python3 support packages

[nilambarirathi16]

What package is missing from Amazon Linux 2023? Please describe and include package name.

• setuptools -> 65.5.1
• requests -> 2.31.0
• urllib3 -> 2.0.7,1.26.18
• configobj -> 5.0.9
• cryptography -> 42.0.2
• Jinja2 -> 3.1.3
• idna -> 3.7

Is this an update to existing package or new package request?
Update to an existing package

Is this package available in Amazon Linux 2? If it is available via external sources such as EPEL, please specify.

Any additional information you'd like to include. (use-cases, etc)
The above-mentioned package contains the High Vulnerability in al2023-ami-ecs-hvm-2023.0.20250310-kernel-6.1-x86_64

[ozbenh]

Do you have specific details about which vulnerability you are concerned about and have you checked our security advisories for the possible presence of backports/fixes ?

[jorge-gonzalez-webbeds]

I think the most important one, and the one I have detected, is cryptography: CVE-2023-0286. This vulnerability cannot be mitigated unless AWS CLI is updated. However, the latest version available via yum detects that it is already up-to-date, so you have to manually download the binary using curl.

Here is the advisory for the cryptography package: GHSA-x4qr-2fvf-3mr5.

Could you confirm if there are any backported fixes for this issue in Amazon Linux 2023?

[stewartsmith]

Amazon Linux near universally ensures software packages link to central shared libraries, so when we update them, all packages that depend on that library get updated.

The python3-cryptography RPM that is part of Amazon Linux 2023 is not statically linked with OpenSSL. Thus, CVE-2023-0286 is patched as part of ALAS-2023-101 when OpenSSL was updated.

It appears that the upstream Python cryptography project distributes a binary wheel which includes an embedded copy of OpenSSL. This is different to the binary that is in the RPM that you can install from the Amazon Linux 2023 repositories.

Does this answer your question?

[cpasquini]

We are seeing similar CVE findings from the Wiz.io service that scans our instances for vulnerabilities; specifically around CVE-2023-0286:

Description
The library cryptography version 36.0.1 was detected in PIP library manager located at /usr/lib64/python3.9/site-packages/cryptography-36.0.1-py3.9.egg-info/PKG-INFO and is vulnerable to CVE-2023-0286, which exists in versions >= 0.8.1, < 39.0.1.

The vulnerability was found in the Github Security Advisory with vendor severity: High (NVD severity: High).

The vulnerability can be remediated by updating the library to version 39.0.1 or higher, using pip install --upgrade cryptography.


Name
CVE-2023-0286

Since these system packages are not installed via pip, what options would we have to address? Or is this a false positive?

The package manager is still showing the version as 36.0.1 in the latest Amazon Linux 2023 AMI.

sh-5.2$ yum list installed|grep python3-cryptography
python3-cryptography.x86_64            36.0.1-1.amzn2023.0.6              @System

Additional info shows that the python-cryptography package is using the embedded version 3.0.8 of openssl:

sh-5.2$ python3
Python 3.9.20 (main, Jan 25 2025, 00:00:00)
[GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> import cryptography.hazmat.backends.openssl

>>> cryptography.hazmat.backends.openssl.backend.openssl_version_text()
'OpenSSL 3.0.8 7 Feb 2023'

[ozbenh]

[ec2-user@ip-172-31-17-247 ~]$ ldd /usr/lib64/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
	linux-vdso.so.1 (0x00007ffd0c167000)
	libssl.so.3 => /lib64/libssl.so.3 (0x00007f5d5f2d1000)
	libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f5d5ee00000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f5d5ea00000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f5d5f2b7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5d5f433000)

As you can see, the hazmat backend is just a wrapper around the installed openssl shared library (which is provided by the openssl package). So this is a false positive from Wiz.io. As @stewartsmith explained, the RPM variant of python3-cryptography that we ship does not embed its own version of openssl.

[stewartsmith]

Looks like there's no issue with Amazon Linux here, and rather an issue with Wiz.io and how it scans Amazon Linux 2023. I'm going to close this issue, but feel free to reopen if there is something else found.

[cpasquini]

Wiz and other scanning tools will go by the version of the package. Does AWS not increment package versions to match what would show up through pip?

[ozbenh]

It is common for distros like Amazon Linux (or RHEL) to backport fixes to older versions of packages, so generally just looking at a version of a package without specific knowledge about the distro isn't going to work. Scanners should be aware of that and are expected to have distro specific rules. We also publish CVE information on our own ALAS.

In this specific case, this seems to stem from an incorrect assumption that python-cryptography bundles its own copy of openssl so this is bogus no matter the version (and there is no telling what version of openssl a given build of it might have bundled, making assumptions based on specific binary artifacts provided upstream isn't going to be applicable to most distros).

Now that doesn't mean we might not decide to update python-cryptography at some point for other reasons, either due to security issues actually present in there, or bugs/features, provide we are confident the update is safe and won't break existing customer workloads, but the version we ship is not affected by the CVE and in this specific case, you should report to Wiz that their scanning is producing incorrect results.

[ozbenh]

Another example of the above is RHEL 9 which also ships python3-cryptography 36.0.1