For a few days now, the security world has been talking about new vulnerabilities, (CVE-2022-3602 and CVE-2022-3786) in OpenSSL. These vulnerabilities were reported to the OpenSSL project on October 17th, 2022.
The vulnerabilities, which up until recently lacked details, were hyped to be the next Heartbleed (can you believe it’s been so long?) as they were initially classified as critical. However, on November 1st, 2022, the OpenSSL project released its security advisory with details about the vulnerabilities. In their advisory, OpenSSL categorized the vulnerabilities’ severity as high and not critical.
Several companies have already released some very good analyses on the vulnerabilities, the best of them, in my opinion, was this very thorough blog post by the Datadog security labs team.
Most of those writeups discuss the ramifications of said vulnerabilities on regular Linux and Windows servers, however, they don’t discuss how they affect IoT devices. Since as we all know, vulnerabilities in IoT devices, especially ones that are buried deep in a library that is as prevalent as OpenSSL, can leave these devices vulnerable for years to come.
In this blog post, we’ll shed some light on how those vulnerabilities can affect IoT devices and how Sternum can mitigate this vulnerability (and others) without installing a single patch or firmware update.
Both of these OpenSSL CVEs detail a stack buffer overflow vulnerability that can be triggered via the X.509 certificate verification process, specifically in name constraint checking. Successful exploitation of this vulnerability can lead to a crash caused by a buffer overflow and possibly remote code execution.
With that being said, in “regular” Linux machines these vulnerabilities become even harder to exploit due to various compiler optimizations and security features such as stack canaries.
However, many IoT devices do not have such protections, or if they do, they are not turned on by default. Whether it is because of old kernel versions, resource constraints, or just features not being enabled by default in those devices’ toolchains – the fact is that in the IoT world stack buffer overflows and execution flow manipulations are still a big threat.
Common IoT devices toolchain with buffer overflow protection off by default
It is important to emphasize that achieving remote code execution with these vulnerabilities is extremely non-trivial, since the attacker can only overflow the stack buffer by 4 bytes. However, a DoS (denial of service) can still be achieved if the attacker crashes OpenSSL.
Easy fix for computers. Not so much for IoT.
When examining the fix over on OpenSSL’s github repository we can see that this vulnerability was an off-by-one that was easily solved by adding an equal sign to the Punycode check routine.
Screenshot of the OpenSSL fix from Github
In regular computers and servers, updating OpenSSL would be a fairly straightforward task, usually consisting of updating the OpenSSL package on the machine. However, on IoT devices, the process becomes much more complex.
In the vast majority of cases, it requires a full firmware update which in turn requires a full rebuild of the packages in the firmware that is dependent on OpenSSL or have OpenSSL statically linked/bundled into them, and of course, OpenSSL itself.
As we all know, there is no guarantee that once a device is released to the market it will continue to receive firmware updates. Moreover, in many cases, the firmware update itself is not a straightforward or automated process. This requires the operators of the device to perform it on every device individually and manually which can lead to substantial downtimes and errors.
Runtime security = Built-in protection
So what can the IoT industry do to mitigate this and future threats?
The answer is runtime protection.
Our patented EIV (embedded integrity verification) technology introduces the concept of runtime/RASP-like security to IoT devices, which allows it to deterministically prevent memory and command flow exploitations, provide out-of-the-box protection from these OpenSSL vulnerabilities, and other undiscovered or zero-day threats.
The solution is agentless, embedding itself within the device’s code to ensure the integrity of all runtime processes, including memory usage and allocation (e.g., preventing memory corruption attacks). Running whenever and wherever the code runs, it immediately stops any unexpected variation or exploits.
In this specific case, it means that it was able to protect from CVE-2022-3602 and CVE-2022-3786 by default, ensuring the security of all Sternum-protected Linux and RTOS devices, even if they didn’t have stack canaries and other memory protections enabled by the operating system or device manufacturer.
For us, and our customers, this is a good example of the peace of mind you have with autonomous solutions when it comes to IoT firmware vulnerabilities – especially for those obscure ones that may never be patched.