CentOS

As per the Apache release, the latest version of HTTP is 2.4.58, but we are not able to update to the latest version in the Centos 9 stream. even after reinstalling the version still 2.4.57.

You need to read https://access.redhat.com/security/updates/backporting/ for information on backporting of security fixes and features in CentOS and RHEL. Additionally https://access.redhat.com/solutions/2074 may also be of use.

Upgrading to the current upstream version is not how CentOS/RHEL works.

And if security is a concern, then Stream may not be the best choice:
Stream is a rolling pre-release (aka. beta) of the next RHEL point
release. It may be better to use one of the RHEL clones/rebuilds like
Rocky, Alma, OEL etc.

The changelog for 2.4.58 lists the following CVEs as fixed and these are the links to the RH info about those.

https://access.redhat.com/security/cve/CVE-2023-45802
https://access.redhat.com/security/cve/CVE-2023-43622
https://access.redhat.com/security/cve/CVE-2023-31122

There is a Tenable report that says HTTP version 2.4.57 is vulnerable and needs to be upgraded to the latest version. While checking there is no repo for 2.4.58. Is it possible to update the HTTP to the latest version in Centos 9 stream??

Did you read the description of backporting? The "2.4.57" in RHEL is not the 2.4.57.

Yes. I understood the backporting, But could you please tell me how can we provide proof against it to get an exception from the vulnerability incident? We will need proof that this version is not vulnerable. Is that possible?

Read the CVE links to RH that I posted. They often have mitigations that you can use. If and when they fix them in RHEL then they will be fixed in the rebuilds. Stream is a special case and may not get the fix until later or maybe it'll get it first.

telxsi wrote: ↑

2024/02/08 09:52:55

We will need proof

If you do need proof, then you probably have a "production system" and one does not use CentOS Stream for production.


Take a system that you do know to be vulnerable and exploit the vulnerability. Now you know that your exploit "works".
Then repeat on your CentOS Stream system. If the exploit "succeeds" there too, then Stream is vulnerable.
Alas, your failure to exploit a Stream system is not complete proof that Stream is not vulnerable.

Also Tenable checks often use the service "banner" information to determine if a system is vulnerable. It does not check if the exploit actually is present, it just looks at the banner returned in the e.g. http headers and says "oh, httpd 2.4.57 is not 2.4.58" and does not check if it is actually exploitable. Red Hat backports do not change the version number even when the problem is fixed so these sorts of checks are often unreliable.

In this particular case the CVE pages say that RH have not yet fixed the problem. For one of the vulnerabilities there is a documented bypass for the problem in that CVE page https://access.redhat.com/security/cve/CVE-2023-31122 and a 2nd one says "During "normal" HTTP/2 use, the probability of encountering this issue is very low".