When OpenSSL initially announced a critical vulnerabilities (now CVE-2022-37786 and CVE-2022-3602) in its platform, organizations scrambled to prepare for its patch in order to ensure the safety of their businesses. However, when the patch arrived Tuesday, OpenSSL reassessed their vulnerabilities as “high” rather than critical.
Mike Turner, VP WW of solution engineering, AppViewX shared his thoughts on the danger of these Open SSL vulnerabilities: “Despite the change in the assessment on the criticality of the vulnerabilities and the likelihood of an attacker being able to exploit, OpenSSL’s rankings make sense. However, this doesn’t mean that organizations should not immediately take action and remediate these vulnerabilities. While they are no longer considered critical, they are now publicly announced and that increases the risk of an outsider weaponizing them.
Although some question OpenSSL’s decision to pre-disclose the details of the vulnerabilities before the patch, the good news here is that the early disclosure gave cyber defenders an
opportunity to be prepared for the worst. A “high” classified vulnerability should still be taken seriously and in some cases, this vulnerability could be of a critical nature depending upon how buffers were arranged on the stack and if remote code execution could still be possible. Applying the patch and monitoring for threats should be part of your immediate cyber hygiene plans.
That said, from the initial announcement, some compared this instance to the Heartbleed bug. The reality is, the disclosure of the OpenSSL vulnerabilities as “high” was a big relief along with the release of the patch. With the pervasive use of OpenSSL in all types of commercial and embedded software applications, we were expecting much worse if the CVEs were critical as last week’s warnings were suggesting. The likelihood of exploitability is now much lower, but there is once again a spotlight on OpenSSL and other widely used open source components. Developers continue to open source components like OpenSSL and Log4j because they don’t need to create code for functionality that is widely available. While this does accelerate the development process, it can put consumers/users at risk. As with what we learned with Log4j, documenting the open source code used in the software supply chain is needed more than ever to know where potential vulnerabilities may be hiding in the applications that we use and rely on.”