Security patches are not updated in Centos 7

[amityweb]

A security supplier has identified vulnerabilities due to using httpd < 2.4.54.

I explained that its an old version but it is patched for security updated.

but when I ran rpm -q --changelog httpd | grep CVE, I get the below which is quite outdated…

So why is it not patched anymore? I thought Centos 7 end of life is June 30, 2024

I have other software reported outdated too, so could be others not just httpd.

SYSTEM INFORMATION
CentOS Linux 7.9.2009
Webmin version: 1.994
Virtualmin version: 7.1

`[]  rpm -q --changelog httpd | grep CVE,`
- Resolves: #2031072 - **CVE**-2021-34798 httpd: NULL pointer dereference via
- Resolves: #2031074 - **CVE**-2021-39275 httpd: out-of-bounds write in
- Resolves: #1969226 - **CVE**-2021-26691 httpd: Heap overflow in mod_session
- Resolves: #2035058 - **CVE**-2021-44790 httpd: mod_lua: possible buffer overflow
- Resolves: #2015694 - proxy rewrite to unix socket fails with **CVE**-2021-40438 fix
- Resolves: #2011729 - **CVE**-2021-40438 httpd: mod_proxy: SSRF via a crafted
- Resolves: #1823262 - **CVE**-2020-1934 httpd: mod_proxy_ftp use of uninitialized
- Resolves: #1565491 - **CVE**-2017-15715 httpd: <FilesMatch> bypass with a trailing
- Resolves: #1747283 - **CVE**-2019-10098 httpd: mod_rewrite potential open redirect
- Resolves: #1565457 - **CVE**-2018-1303 httpd: Out of bounds read in
- Resolves: #1566531 - **CVE**-2018-1283 httpd: Improper handling of headers in
- Resolves: #1677496 - **CVE**-2018-17199 httpd: mod_session_cookie does not respect
- Resolves: #1565465 - **CVE**-2017-15710 httpd: Out of bound write in
- Resolves: #1568298 - **CVE**-2018-1301 httpd: Out of bounds access after
- Resolves: #1566317 - **CVE**-2018-1312 httpd: Weak Digest auth nonce generation
- Resolves: #1696141 - **CVE**-2019-0217 httpd: mod_auth_digest: access control
- Resolves: #1696096 - **CVE**-2019-0220 httpd: URL normalization inconsistency
- Resolves: #1493065 - **CVE**-2017-9798 httpd: Use-after-free by limiting
- Resolves: #1463194 - **CVE**-2017-3167 httpd: ap_get_basic_auth_pw()
- Resolves: #1463197 - **CVE**-2017-3169 httpd: mod_ssl NULL pointer dereference
- Resolves: #1463207 - **CVE**-2017-7679 httpd: mod_mime buffer overread
- Resolves: #1463205 - **CVE**-2017-7668 httpd: ap_find_token() buffer overread
- Resolves: #1470748 - **CVE**-2017-9788 httpd: Uninitialized memory reflection
- Related: #1412976 - **CVE**-2016-0736 **CVE**-2016-2161 **CVE**-2016-8743
- Resolves: #1412976 - **CVE**-2016-0736 **CVE**-2016-2161 **CVE**-2016-8743
- add security fix for **CVE**-2016-5387
- core: fix chunk header parsing defect (**CVE**-2015-3183)
and ap_force_authn hook (**CVE**-2015-3185)
- core: fix bypassing of mod_headers rules via chunked requests (**CVE**-2013-5704)
- mod_cache: fix NULL pointer dereference on empty Content-Type (**CVE**-2014-3581)
- mod_cgid: add security fix for **CVE**-2014-0231 (#1120608)
- mod_proxy: add security fix for **CVE**-2014-0117 (#1120608)
- mod_deflate: add security fix for **CVE**-2014-0118 (#1120608)
- mod_status: add security fix for **CVE**-2014-0226 (#1120608)
- mod_cache: add secutiry fix for **CVE**-2013-4352 (#1120608)
- mod_dav: add security fix for **CVE**-2013-6438 (#1077907)
- mod_log_config: add security fix for **CVE**-2014-0098 (#1077907)

[tpnsolutions]

@amityweb,

How did they identify vulnerabilities?

RedHat who essentially provides to underlying code for CentOS uses a “backporting” model which works something like this.

1. Apache issues a new version of httpd to the public with patches, and new features.

2. RedHat doesn’t want “new features”, but identifies that new version has “security patches” which apply to the version they support, so they extract those updates and apply it to a new version of their maintained “httpd”, and release it to their community.

This model allows them to fix bugs, without introducing new features that have not yet been vetted for the current version of “httpd” they support.

[amityweb]

They are likely to use software which identifies the version.

Yes I informed them of the back porting for security. So thats not the issue here… its the fact that all the recent exploits are not patched yet. It only goes back to January. There have been new ones this year.

For example, this one in Apache CVE-2022-23943. Its not in my changelog so I assume its not patched. I have done a yum update on the system.
https://access.redhat.com/security/cve/cve-2022-23943

Is it because that page says its “Out of support scope”? If so, why would that be, when I read support is to June 2024?

See attached for a selection of them.

[tpnsolutions]

@amityweb,

I guess you failed to read their “mitigation” steps…

The bug doesn’t affect a system NOT using “mod_sed”, which is likely the case. You’d have to have added the “mod_sed” module to your installation for you to be affected by the CVE. Virtualmin does NOT come shipped with this module installed or enabled. Therefore the CVE in question does NOT affect your system.

Disabling mod_sed and restarting httpd will mitigate this flaw. See https://access.redhat.com/articles/10649 for more information.

[amityweb]

No, I assumed its a software update that would fix it. So therefore this specific issue is not a software update, but a configuration change?

So are ALL the other security issues the same, they are not software updates but config changes? And so therefore httpd-2.4.6-97.el7 is the latest version with all available security patches? Then this list above is just changing server settings?

I have just checked a few of the issues and they all have mitigation by way of changing settings, e.g uninstalling openssh client. So maybe they are then.

If thats correct then the report I uploaded is deceiving, it implies the issues exist due to versions being less than it stated!

Thanks for your help in identifying this as I never noticed and just assumed it was software patches.

[Joe]

That’s not what Peter is saying.

There are two ways to solve a security problem with a piece of software:

1. Update it to patch the bug.
2. Disable it, so the impacted code is not exposed, or otherwise mitigate it (isolation, change limits, whatever).

Peter pointed out that in the case of one of those issues, a default Virtualmin system is not vulnerable because we don’t use the module in question. If you didn’t install/enable that module, then you are also not vulnerable.

Mitigation and updates are not the same thing. They’re two ways to solve a security problem.

[Joe]

And, if you must use features/modules/etc. in Apache that are not patched in CentOS 7, you should consider upgrading to a newer OS. CentOS 7 is over six years old at this point, and it is, by policy, locked into using six+ year old versions of everything in the system.