Few libraries are in widespread use as OpenSSL. It has a ubiquitous presence across hardware platforms and operating systems, userland applications and IoT. The chances are good that the web browser you are using right now to read this page is relying in some way on OpenSSL to negotiate the “s” in the “https” with the webserver.
Together with curl, zlib and glibc, it’s one of the names that make sysadmins tremble whenever they appear in the same sentence as “new vulnerabilities found”. Unfortunately, today is another of those days. Two new vulnerabilities have emerged for OpenSSL; one is considered “High” severity and the other “Low” severity. They affect all OpenSSL 1.1.1 versions, as well as the current beta/alpha versions of 3.0.0, but the final version of that series will include the fixes.
TuxCare’s Live Patching service has already prepared patches which are already being delivered – in the same day the vulnerabilities were announced – for EL8 based distributions, as well as Debian 10, Ubuntu 18.04 and 20.04 – the ones shipping the affected versions of OpenSSL.
Starting with CVE-2021-3712, it was found that several different locations throughout the OpenSSL code improperly assume that ASN.1 strings are always NUL terminated. NUL termination is jargon for a sequence of characters that ends with the NUL byte (0). Programmers often use it when looking for the end of a string – i.e., they go through it until they find the said NUL byte. It so happens that it is possible to construct these strings outside of OpenSSL functions and then pass them into OpenSSL for processing, which can, for a properly motivated malicious actor, lead to buffer overruns and be a pathway to memory corruption. From previous exploits using similar techniques, we know that this may eventually lead to privilege escalation.
It’s important to note that, in the commit message for the fix in the OpenSSL code repository, the author mentions specifically that the fix is only for the instances he was able to find. More uses of ASN.1 strings assumed to be NUL terminated may still linger in the codebase. It is not unthinkable that, in the near future, further code fixes may be necessary to address issues exactly like this one.
On a more practical note, functions in OpenSSL that are known to be vulnerable to this problem include, but are not limited to, the ones relating to name validation in certificates, in situations where the certificate is not directly constructed through OpenSSL but instead passed to OpenSSL for validation.
Moving forward to CVE-2021-3711, the vulnerability rated as “High” severity is related to SM2 decryption. SM2 is an elliptic curve-based algorithm. OpenSSL includes several different functions supporting this algorithm, including EVP_PKEY_DECRYPT(). This function is typically called twice, the first to discover the size of the buffer needed to hold the data and the second to actually perform the decryption, this time also passing the properly sized buffer to it.
It turns out that, due to a bug in the implementation of this function, it is possible to receive a buffer size in the first call that is actually smaller than the required buffer size for the second call, in which case the calling application will be passing a buffer that is too small to hold the whole data, leading to a buffer overflow. This can cause memory corruption, which, as previously mentioned, has been shown to lead to more dangerous outcomes for properly motivated attackers.
TuxCare’s Team continues to track these vulnerabilities and assess how they may impact our service subscribers’ systems, providing fixes where appropriate.
If you would like to know more about TuxCare’s services, you can find details here.