OpenSSL has been forced to issue an emergency security update to one of its patches after it was found to introduce a critical flaw of its own.
The new vulnerability affects OpenSSL 1.1.0a, which was published last week. OpenSSL has urged users to update to 1.1.0b immediately.
The original update fixed CVE-2016-6307. This flaw caused excessive memory allocation in tls_get_message_header. While this was marked as a low severity issue, it could cause a server to crash.
But the patch created a new flaw where if a message larger than approx 16k is received then the underlying buffer to store the incoming message is reallocated and moved.
“Unfortunately a dangling pointer to the old location is left which results in an attempt to write to the previously freed location. This is likely to result in a crash, however it could potentially lead to execution of arbitrary code,” the organisation said in a security advisory.
The advisory also included a fix for a flaw affecting OpenSSL 1.0.2i, also released last week. CVE-2016-7052 describes a missing certificate revocation list (CRL) sanity check component. This update includes a CRL sanity check was added to OpenSSL 1.1.0 but was omitted from OpenSSL 1.0.2i.
“As a result any attempt to use CRLs in OpenSSL 1.0.2i will crash with a null pointer exception,” the advisory stated.
The OpenSSL open source project released versions 1.1.0a, 1.0.2i, and 1.0.1u of the library last week. The most serious vulnerability bug drove content distribution network, Akamai, to immediately roll out the update.
The latest patched code is available here.
Neil Cook, chief security architect at Open-Xchange, told SCMagazineUK.com that there is sometimes a tension between trying to release a security patch as quickly as possible in order to resolve a vulnerability, and extensive QA to ensure the patch is functional.
“Often the QA to test a security patch will not be as extensive as the QA performed on a “normal” release, which can be understandable given the time constraints.”
He said that organisations implementing the patch may have noticed the patch was faulty as their applications would typically have crashed, as this was a case of accessing freed memory. “Under some circumstances this could have led to executing arbitrary code, but this is unlikely.”
“For software developers, ideally security patches should be tested in the same way as normal product releases, by using automated test suites combined with a QA team to conduct full regression testing as well as testing the particular behaviour being patched, in order to ensure the fix doesn't have side effects,” said Cook.
Chris Fearon, research director at Black Duck, told SC that from an operations stand point, organisations must ensure a robust response plan is rehearsed as with any security patches to mass adopted components.
“Understanding the risks posed to your business will allow for a greater understanding of the vulnerabilities which should be of most concern. Identifying these categories of vulnerabilities will facilitate a greater vulnerability and risk management programme increasing focus and operational response to future vulnerabilities including incorrect fixes for existing weaknesses,” added Fearon.