The OpenSSL project has been scrambling to get a badly needed patch out the door. OpenSSL, the cryptographic library used in many servers, released versions 1.1.0a, 1.0.2i and 1.0.1u on Sept. 22 to address more than a dozen security holes that had been affecting the software.

OpenSSL Patch Creates New Problems

The most serious vulnerability addressed in these releases, SecurityWeek reported, is CVE-2016-6304. This vulnerability can be exploited to conduct distributed denial-of-service (DDoS) attacks by sending an excessively large OCSP status request extension to the targeted server.

The OpenSSL patch also addressed excessive memory allocation in a header. This low-severity vulnerability (CVE-2016-6307) can only be exploited if certain specific conditions are met. However, OpenSSL fixed this problem with version 1.1.0a — or so it thought.

Patches Upon Patches

OpenSSL issued an advisory on Sept. 26 to address problems caused by the aforementioned updates.

Version 1.1.0a introduced a new, critical vulnerability that could lead to a crash or execution of arbitrary code. OpenSSL explained that this occurs when the server receives a message that exceeds 16k, resulting in the relocation and reallocation of the underlying buffer to store the incoming message.

“Unfortunately,” the advisory read, “a dangling pointer to the old location is left, which results in an attempt to write to the previously freed location.”

OpenSSL fixed the issue with version 1.1.0b.

Sanity Check

OpenSSL also dropped a sanity check in the first release. A bug fix including a CRL sanity check was added to OpenSSL 1.1.0. However, the code didn’t make it into OpenSSL 1.0.2i. This means any attempt to use CRLs in version 1.0.2i will crash with a null pointer exception. OpenSSL 1.0.2i users should upgrade to 1.0.2j.

In some respects, the agility with which OpenSSL identified and fixed these vulnerabilities is commendable. The project recognized the problem and quickly issued an advisory to rectify it.

Considering the unintended consequences of the Sept. 22 release, however, one can only hope OpenSSL found time to conduct the necessary testing for this batch of new software.