OpenSSL 1.1.1k Two High Severity Vulnerabilities Explored

When determining the validity of certificate chains, OpenSSL allows for programmatic “modes” that determine how stringent the rules engine used for determining validity will be. For example, the X509_V_FLAG_NO_ALT_CHAINS flag determines OpenSSL’s behavior after finding an invalid chain. Legacy software used to immediately return false in these scenarios, but it is extremely useful for OpenSSL to continue looking for an alternative valid path, for example, for when a long-lived intermediate certificate expires. (Earlier this year such a certificate from Sectigo expired wreaking havoc across the internet). CVE-2021-3450 specifically involves the flag X509_V_FLAG_X509_STRICT. This flag is off by default, and typically used in extremely controlled deployments where tight security is valued over wide compatibility. This makes this bug unlikely to affect everyday users, but especially unfortunate for software packages which make use of this flag and reach out to an endpoint which does not have the “purpose” field set on the certificate. This unlikely combination of circumstances triggers OpenSSL to not correctly ensure that the issuer is a valid CA.

This can be a tough thing to ascertain, as even if you update your server’s version of OpenSSL to 1.1.1k, any application has the potential to be statically compiled against libssl’s client or server libraries. The best thing to do is to contact your vendors and ask for their statement on whether they are impacted by this vulnerability. Some companies, such as Redhat, preemptively put out a statement defining impact. (RedHat itself is not impacted because while it relies on OpenSSL and LibSSL, does not set the STRICT flag.

access.redhat.com/security/cve/CVE-2021-3450

Renegotiation bugs represent a surprisingly large slice of the pie if you look at historical bugs in the OpenSSL software. Over the years errors in implementing re-negotiation have led to man-in-the-middle attacks later collectively termed “insecure renegotiation”. (One particular bug CVE-2009-3555 was so severe that at the time disabling renegotiation entirely and accepting the performance penalty). Later, an extension to SSL/TLS the “renegotiation indication extension” was created which allows for keeping track of certain session information from the original handshake allowing both sides to detect if a bad actor is trying to pass off initial negotiation as if it were a renegotiation, as well as several of the other dastardly tricks in the bad guy’s arsenal.

CVE-2021-3449 is a new way in which re-negotiation causes problems: an attacker can trick servers using TLS 1.2 in the default configuration into attempting to dereference a null pointer by constructing an ClientHello message specifying the signature_algorithm extension, followed by a renegotiation which includes the signature_algorithms_cert extension WITHOUT the signature_algorithm extension. These extensions are usually considered part and parcel, so there would be no legitimate reason to do this. Attempting to dereference a null pointer results in the application crashing. This situation crashes the software, usually requiring administrator intervention.

But what is a null pointer dereference? The dereference operator is a common construct in languages like C or C++ which leave memory management to the programmer. A “pointer” is simply an address of a location in main memory (RAM), (truth be told modern systems use ASLR to purposefully obfuscate memory locations but let’s pretend they don’t for a minute). In a language like C, when you’re interested in reading or writing the contents of the memory location, you “dereference” the pointer. It is somewhat similar to resolving a key to its value in a hash table! A null pointer is a pointer with a value of null (Maybe it was instantiated this way with the programmer intending to populate it later before using it, or maybe it was nulled out later). Therefore, putting it all together, a null pointer dereference is what happens when a program tries to get the value at memory address NULL. If it seems shocking that there is no way to prevent this condition from resulting in a error, you must remember that this occurs at such a low level in the stack that there is no way to protect against this except to not tell the computer to do it in the first place! Null pointer exceptions invariably are the result of a condition the programmer does not anticipate.

This particular bug is exceptionally easy to trigger. In many cases stopping a service abruptly can have far-reaching consequences – imagine the cascading failures possible on a storage device or a network appliance.

If you are using OpenSSL, you are almost definitely affected! TLS 1.2 is by far the most popular version of TLS, and renegotiation is enabled by default. If your change management process prohibits you from upgrade to OpenSSL 1.1.1k, or if a particular piece of software has not yet released a patch, it might be worth disabling renegotiation entirely. Additionally, any server software built against LibSSL that is statically compiled will need to be recompiled against a version of the library not vulnerable to this availability issue.

There is the potential for any software to have bugs, but OpenSSL is as ubiquitous as it is crucial. The most important take-away is the importance of best network practices and defense-in-depth. When issues like these happen, those most at risk are the ones who expose services to the internet needlessly, lack proper network segmentation internally, or who do not keep up to date on the latest news and threats. Bugs like CVE-2021-3449 are especially unfortunate, because they are attractive to script kiddies. It is extremely likely that in the next few weeks we will see “spray and pray” type attacks over the entirety of the IPV4 and IPV6 public address spaces! It is a good time not only to address these vulnerabilities, but to revisit any services open to the outside world. While it is not appropriate in all circumstances, it is also whether considering whether TLS renegotiation adds value to you and your business, or whether it would be worth disabling permanently and entirely. After all, as of TLS 1.3, TLS renegotiation is abandoned completely, and the receipt of a ClientHello outside of the initial renegotiation results in a severed connection.