OpenSSL, a toolkit used for encrypted communication, recently discovered that a previous patch had flaws. The bugged patch was intended to fix CVE-2016-6307, which affected memory allocation in tls_get_message_header. The end result of this flaw would be frequent server crashes, but it turns out that the patch caused even worse problems. Aside from not fixing the server crash, the bugged patch also allows for execution of arbitrary code.
The newest patch, OpenSSL 1.1.0b, will fix this issue entirely. Still, one has to wonder how the previous patch could have been so flawed in the first place. Keep this in mind, CVE-2016-6307 was considered to be a “low-severity” bug. Once the patch was installed, however, the vulnerability became reclassified as having “critical-severity.” You really have to wonder how such a major issue occurred in the patch’s creation, and why OpenSSL pushed this out before testing it extensively.
A lesson exists here for any security professional in charge of applying patches to their networks. In case you forgot our basic training, one of the earliest things we are taught in certification programs, like COMPTIA Security+, is to never patch immediately. We must find a way to isolate the item that needs patching from the rest of the network. Once this is done, then
the patch can be applied and checked for any major flaws.
The problem is that many — and I mean many — organizations do not actually do this. One of my sources at Lockheed Martin has told me how the company used to push through patches right away. Lockheed Martin learned the hard way when one of these patches was severely flawed. Now the company patches, thankfully, at least a day after the patch is released to make sure there are no issues that will afflict the entire network. More security divisions must do the same, as bugged patches like OpenSSL 1.1.0a are not going to stop occurring any time soon.
Photo Credit: OpenSSL Authors
