My site is having compliance issues and I know enough to understand for example resolving failing openssl CVEs does NOT involve 'upgrading' openssl per se but instead checking its patch status(?). However, when I do so it appears I am not covered for specific patches and am unsure as how to add protection.
I am running openssl 1.0.2k, release 22.e17_9 on a CentoS7 server
When I query some of the CVEs I get a response to indicate it has been patched (see CVE 2021-23840 below)
[***]# rpm -q --changelog openssl | grep CVE-2021-23840
- fix CVE-2021-23840 openssl: integer overflow in CipherUpdate
However, others (CVE-2020-1968 below) I get no response, I assume meaning I am not patched for it.
[***]# rpm -q --changelog openssl | grep CVE-2020-1968
[***]#
How do I add protection for this CVE? There are 10-15 failing CVEs that all pertain to openssl and hopefully the resolution for one applies to the remainder.
Many thanks for any input you might be able to provide.
patching openssl for compliance
Re: patching openssl for compliance
Looks like Red Hat will not fix it:
https://access.redhat.com/security/cve/cve-2020-1968
https://access.redhat.com/security/cve/cve-2020-1968
Re: patching openssl for compliance
Read the linked bugzilla for a bypass:
"In OpenSSL 1.0.2f and above, this flaw can be mitigated by not enabling static DH ciphersuites. Such ciphersuites start with `DH-` in OpenSSL and are mapped to IANA names that start with `TLS_DH_`, excluding ciphersuites that start with `TLS_DH_anon`. Following this convention, we see that `DH-RSA-AES256-GCM-SHA384` with IANA name `TLS_DH_RSA_WITH_AES_256_GCM_SHA384` is affected and should not be used in a mitigation of this flaw. However, `ECDH-RSA-AES128-GCM-SHA256` with IANA name `TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256` is not affected and may be used in a mitigation to this flaw, as it does not follow the `DH-` or `TLS_DH_` naming convention."
"In OpenSSL 1.0.2f and above, this flaw can be mitigated by not enabling static DH ciphersuites. Such ciphersuites start with `DH-` in OpenSSL and are mapped to IANA names that start with `TLS_DH_`, excluding ciphersuites that start with `TLS_DH_anon`. Following this convention, we see that `DH-RSA-AES256-GCM-SHA384` with IANA name `TLS_DH_RSA_WITH_AES_256_GCM_SHA384` is affected and should not be used in a mitigation of this flaw. However, `ECDH-RSA-AES128-GCM-SHA256` with IANA name `TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256` is not affected and may be used in a mitigation to this flaw, as it does not follow the `DH-` or `TLS_DH_` naming convention."
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: patching openssl for compliance
Many thanks for the information re the bypass. Doing more research I had figured I would migrate to CentOS8 but have spent the last while reading about CentOS Stream and there seems to be some doubt as to the future stability of the project.
I will try to get this CentOS7 through PCI and consider my options. Many thanks once again,
I will try to get this CentOS7 through PCI and consider my options. Many thanks once again,