Any solution to CVE-2022-2068 OpenSSL exploit?

Hello all,
I know back in Sept a thread was opened about CVE-2022-2068, but there were only 2 replies and no real solution was given. This is on a high priority from my management, and I was curious to know if there have been any updates to this? My current installed version of openssl is 1.0.2k-fips. Is there a timetable as to when this will get updated? are there alternative ways to mitigate this issue?

Any help is bery much appreciated.

This doesn’t appear to be remotely exploitable. Why do untrusted people have the ability to place certificates on your FreePBX machine, or why would you install a certificate with a questionable file name.

I think the only certificates that one might hash are CA certificates, and I wouldn’t expect FreePBX systems to need large numbers of these and change them often.

(The topic this should be merged with is CVE-2022-2068 OpenSSL exploit )

I really appreciate your reply and I do understand your follow-up questions as well. But the fact of the matter is that this is classified as a critical severity CVE and I would think it only proper that it should be addressed as such.

Unfortunately, these exploits are still open on our security audits, I do not really see any solution coming forward until there is a replacement to SNG7, since it’s based on CentOS and 1.0.2k is the latest supported version for CentOS and no further development is being done on this platform. Short of manually forcing an upgrade, outside of the yum repos to the offending module (which I am not comfortable doing on production servers without intensive testing). So for now I sit and wait for SNG7s succesor.

The CVE statement from upstream (Redhat) Red Hat Customer Portal - Access to 24x7 support and knowledge

Red Hat Enterprise Linux uses a system-wide store of trusted certificates bundled in a single file and updated via update-ca-trust . The c_rehash script is not included in the default installation on any supported RHEL version and is never executed automatically. For these reasons, this flaw has been rated as having a security impact of Moderate.

TL;DR: the vulnerable script is not installed by default.

Searching an up-to-date Distro:

[root@uc-18982740 ~]# find / -name c_rehash
[root@uc-18982740 ~]#

A version of c_rehash is installed through the Zulu module installer, but that is all.

Back to the statement from Redhat,

Some operating systems distribute this script in a manner where it is automatically executed. On these operating systems, this flaw allows an attacker to execute arbitrary commands with the privileges of the script.

again, this is not a c_rehash distributed by the operating system and automatically executed.

In short you are not vulnerable, even if you are running a certain version of openssl and even if your security scanner (which is not smart! it just looks at version numbers and does no actual reasoning about whether you are vulnerable!) sounds an alarm.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.