Hi ,
We are using Rocky Linux 8.9, which shows various vulnerabilities such as
CVE-2023-32681
CVE-2023-5363
CVE-2023-49083
CVE-2023-38325
And these are getting installed as part of python3.6 which gets installed through OS.
So if we upgrade to Python3.9, the system still shows the above Vulnerabilities
For e.g the Vulnerability related to Cryptography is still there reported as below
/usr/local/lib64/python3.6/site-packages/cryptography-40.0.2.dist-info
So how we can clear this Vulnerability, as this is part of lates OS (Rocky Linux 8.9) installation.
Does the latest Rocky Linux 8.9 been released with Vulnerability, how we can address those security Vulnerability
The problem is that vulnerability scanners use our errata database, and the errata database currently has some missing data. This is currently being fixed. Until then, please verify results by looking up the equivalent RHEL errata.
As Brian has addressed the first one, I’ll reply to the others:
CVE-2023-5363
OpenSSL version 3.0 and 3.1 are affected. Rocky 8 is not because it doesn’t use OpenSSL 3.
CVE-2023-38325
From RH:
CVE-2023-49083
According to Red Hat, this has been fixed in Squid during November 2023.
That would suggest that these vulnerabilties are not present in Rocky 8.9. I googled the CVE number along with RHEL, and each of the corresponding pages from RH give all the relative information.
Even if the vulnerability scanner is using a correctly populated CVE database, it can still report the system as being vulnerable, for example, if the scanner doesn’t have full SSH access to be able to login to the system and check the packages installed. I’ve had this numerous times for example with Nessus. Then when I actually allowed it to login via SSH to actually verify what the system had installed, it then correctly displayed that it wasn’t affected.
I’ve even seen one report that Apache was vulnerable because it’s version number was less than what it expected was installed, when what it should have realised was that RH backport fixes into earlier versions of Apache (in this example, can be whatever X package). The scanner didn’t take this into account.
It’s best to check manually, rather than actually blindly believe the results of what a vulnerability scanner claims.
Rocky 8 does have a Python 3.9 module stream, so you could switch to the module stream and use that - unless you did that already. Either way, some older Python 3.x packages will remain simply because they are system dependencies. If RH need to backport a fix, they will usually do that.
The first CVE that I addressed relates to OpenSSL. As you can see in every page that this linked CVE mentions, it mentions nothing about Python. Therefore, I am curious to how accurate those scanning results are considering that the CVE is related to OpenSSL 3.0 and 3.1
The second CVE-2023-38325 which I also mentions says that from Red Hat, versions of Python less than v40 are not affected. The fact you have it installed under /usr/local/ means this is not a supplied Python version by Red Hat. Correct locations for Python 3.6 or even 3.9 on Red Hat using the modules places such items in /usr/lib64. This means you are not running a version of Python provided by Red Hat or even Rocky. So your vulnerabilities are not caused by packages that exist in Rocky 8. The same applies to the CVE-2023-49083 since it also mentions items found under /usr/local.
You can easily find out what package owns those files. I’ll give an example:
dnf info python3-cryptography-0:3.2.1-6.el8.x86_64
Name : python3-cryptography
Version : 3.2.1
Release : 6.el8
Architecture : x86_64
Size : 558 k
Source : python-cryptography-3.2.1-6.el8.src.rpm
Repository : Rocky_Linux_8_BaseOS
Summary : PyCA's cryptography library
URL : https://cryptography.io/en/latest/
License : ASL 2.0 or BSD
Description : cryptography is a package designed to expose cryptographic primitives and
: recipes to Python developers.
I suggest you check your system properly, since these packages you have installed under /usr/local have nothing to do with Rocky or RHEL. Use the dnf commands to find out what package (if any) owns that file, and then you can look at cleaning up your system and remove the packages that have been installed. Either that, or someone has manually installed Python 3 under /usr/local using some kind of source-based method than utilising the normal channels (RPM repositories).