A patch for a low-severity OpenSSL vulnerability issued last week actually made things worse and created a new, more severe vulnerability in the open source cryptographic library.
In an unusual move, the OpenSSL Project bypassed its usual process for announcing vulnerabilities and patch availability, and it instead rushed out a new set of emergency patches to fix the new critical vulnerability.
“This security update addresses issues that were caused by patches included in our previous security update, released on 22nd September 2016,” the OpenSSL Project wrote. “Given the critical severity of one of these flaws, we have chosen to release this advisory immediately to prevent upgrades to the affected version, rather than delaying in order to provide our usual public pre-notification.”
The original flaw, one of 14 fixed in the OpenSSL patch release on Sept. 22, enabled a transitory denial-of-service attack through memory exhaustion and had a low severity rating; the new vulnerability introduced by the patch could allow an attacker to execute arbitrary code on a victim system.
“Due to the way memory is allocated in OpenSSL, this could mean an attacker could force up to 21 MB to be allocated to service a connection. This could lead to a denial of service through memory exhaustion,” according to the original OpenSSL vulnerability advisory. “However, the excessive message-length check still takes place, and this would cause the connection to immediately fail.” Although, the excessive memory allocation is freed immediately, as long as the application uses the SSL_free() function to free up that allocated memory. “Therefore, the excessive memory allocation will be transitory in nature.”
The new critical OpenSSL vulnerability opened by the patch “resulted in an issue where if a message larger than approximately 16 KB is received, then the underlying buffer to store the incoming message is reallocated and moved,” OpenSSL wrote. “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.”
By Peter Loshin