Tech has plenty of holy wars -- Windows vs Linux, emacs vs vi, and Perl vs Python, to name a few -- and security has its own: vulnerability disclosure. At times it makes sense to publicly disclose a security vulnerability, but the recently revealed out-of-bounds read flaw in OpenSSL isn't one of them.
Attackers can trigger the out-of-bounds read flaw in OpenSSL's b2i_PVK_bio() function with a specially crafted private key, according to a post by Guido Vranken, a software engineer at Intelworks. That could lead to a heap corruption and potentially leak memory contents.
The vulnerability was reported to OpenSSL on Feb. 24, but Vranken said the project team informed him on Feb. 26 that the report, along with other reports submitted around that time, would have to wait until the next release. Vranken publicized the bug on his blog on Mar. 1, the same day OpenSSL released versions 1.0.2g and 1.0.1s. "It's not necessarily more secure to have vulnerable code running on servers for a month of more while attackers, if any (for this vulnerability), are not bound to release cycles and have the advantage of time," he wrote.
The argument that administrators and users have to know about security vulnerabilities right away and can't wait for updates is frequently used to justify public disclosures. Certainly, there are times when openly revealing a bug can spur a lagging company to prioritize the issue and get it fixed.
That was the case with last year's automobile hack, as researchers Charlie Miller and Chris Valasek worked with Chrysler for nine months to fix the security flaw that could let attackers wirelessly break into some vehicles and remotely control a 2015 Jeep Cherokee. Chrysler issued a recall notice within days after the duo's "stunt hack" with Wired's Andy Greenberg at the wheel.
That isn't the case with the OpenSSL flaw since the project team acknowledged the report and indicated it was working on a fix. Even Vranken acknowledged the team has to "conform to deadlines and schedules."
No better, no worse
While it should be fixed at some point, the bug doesn't seem critical enough to warrant pre-emptively disclosing it before a patch. While Vranken didn't provide information regarding severity or exploitability in his post, an entry on VulnDB, a comprehensive vulnerability database from Risk Based Security, suggests this is not a show-stopping, drop-everything-and-get-on-it flaw.
VulnDB rated the flaw as "high," but assigned a base score of 7.8, an exploitability score of 8.6, and an impact score of 7.8. The scores, based on the Common Vulnerability Scoring System as well as other internal classifications and metrics, are used to determine if a vulnerability can be easily exploited and if there is a public exploit available.
This makes the vulnerability "no better or no worse" than the 60-or-so OpenSSL flaws found over the past two years, said Bill Ledingham, CTO of Black Duck Software. "This is another in a long line of vulnerabilities reported against OpenSSL as researchers pore over the code."
It would be a good idea for OpenSSL to make sure similar out-of-bounds read vulnerabilities aren't in other sections of the code, which may wind up being more critical than this particular one.
Not under attack
Another good reason for a public disclosure would be if the flaw was actively under attack and being aware could help administrators beef up their defenses. That isn't the case in this situation, as Vranken wasn't aware of any incidents, and the VulnDB entry doesn't list any, either. Thanks to the disclosure, attackers who didn't know about the issue now have the details and can experiment to craft an exploit, and the defenders don't have an easy way to defend their systems.
IT has to wait for a new OpenSSL release, which they had to do before the disclosure -- so nothing has been gained by jumping the gun. For the moment, administrators with OpenSSL in their environments can rest assured they don't need to do anything about this specific bug.
Responsible disclosure may take longer and may not be as exciting, but it helps improve overall security because by the time the details are public, the fix is available. There's some comfort in being able to say, yes, this is a serious issue, but look, here's what can be done to address it to protect the systems/network. The endless drumbeat of software vulnerabilities can wear down even the most security-conscious IT administrator, especially when it's not clear how it can be exploited, whether there's an active threat, or even what to do as a result of the bug report.
Researchers need to think through the vulnerability's actual impact. Just because it's potentially serious doesn't automatically make it critical. There are only so many times people can be told there is nothing they can do about a serious flaw before they start ignoring vulnerability reports altogether. That's not what anyone wants to see happen in IT security.