The OpenSSL Project stated recently that it would release a patch on November 1, 2022, to fix a critical OpenSLL vulnerability. Information on how to stop vulnerability exploitation was kept secret prior to the release of the patch. The reports regarding the vulnerability worried the open source community and other entities because of the magnitude of OpenSLL application. It is broadly employed to encrypt HTTPS connections and
communication channels. Therefore, the effects of such a vulnerability are massive.
The reports of a critical vulnerability remind about the Heartbleed Bug (CVE-2014-0160) which was used to read the memory of systems which include servers and routers to bug communications. The patch was released 8 years ago but 240, 000 publicly accessible servers are still vulnerable to Heartbleed.
The most recent vulnerability impacts versions 3.0 to 3.06 of OpenSLL. Last year, version 3 was just released, therefore usage of the most recent version is restricted. Nevertheless, there is a potential for the vulnerability to be extremely critical and is a big cause of concern. How serious it can be depends on the number of vulnerable instances of OpenSSL3.x in the environment and the ability to precisely identify them to apply the patch as soon as it is available. A lot of companies have difficulties identifying the vulnerable instances, which is why it took a long time to patch the Heartbleed bug.
The OpenSSL Project declared the release of the patch for the vulnerability on November 1, 2022 from 13:00 to 1700 UTC.
However, the OpenSSL Project has just stated that there are two vulnerabilities — CVE-2022-3602 and CVE-2022-3786. The severity of the vulnerabilities was reduced from critical to high severity, and vulnerability exploitation will be hard and demand a high degree of technical ability.
If an attacker exploits CVE-2022-3602, a 4-byte stack buffer overflow, there might be a crash or possibly a remote code execution. An attacker can exploit CVE-2022-3786, a buffer overflow problem, utilizing malicious email addresses during a denial-of-service attack.
The OpenSSL Project mentioned that upon issuing the patches, it didn’t know of any working exploit available in the public domain that would enable remote code execution. There was also no proof identified that suggests the exploitation of either vulnerability thus far.
The Health Sector Cybersecurity Coordination Center released a notification concerning the vulnerability immediately after the OpenSSL Project reported that a patch will be released, cautioning that vulnerability exploitation was very probable, and may begin at once after publishing the patch. Although the scope of the vulnerabilities is minimized, exploitation remains likely, therefore immediate patching is suggested when OpenSSL 3.0-3.0.6 was utilized. Thankfully, the vulnerable models of OpenSSL are not yet seriously deployed in manufacturing. Presently, from 7,000 to 16,000 systems are compromised online and are using vulnerable versions of OpenSSL.
Bugs exploitation would demand a high degree of technical proficiency, which restricts the possibilities for exploitation. Researcher Marcus Hutchins stated that although one of the vulnerabilities could in theory result in RCE, it is incredibly unlikely for the vulnerability to be exploited and cause RCE.
Having said that, OpenSSL states that OpenSSL is distributed as source code, and it does not know the way each platform and compiler mix has put in place the buffers on the collection, and consequently remote code execution might still be likely on a number of platforms.
A listing of products proven to be impacted by the OpenSSL vulnerabilities is being kept here.
Akamai has introduced YARA Regulations and OSQuery questions that may be employed to identify vulnerable cases.