研究人员最近披露称，OpenSSL安全漏洞披露可能在更新发布前的空档期造成更严重的潜在后果。
技术领域的斗争可谓古来有之——Windows对Linux、emacs对vi乃至Perl对Python，而如今安全领域也有了自己的争端——安全漏洞披露方式。曾几何时，公开发布安全漏洞被作为业界共识，然而最近人们发现公布与OpenSSL相当之漏洞却往往反生祸端。
攻击者们能够利用一套经过精心设计的私有密钥立足于外部读取OpenSSL中b2i_PVK_bio()函数中的漏洞说明，Intelworks公司软件工程师Guido Vranken在一篇博文中指出。这可能导致某些与漏洞及缺陷相关的内存内容遭到外泄。
这项安全漏洞于今年2月24号被报告至OpenSSL，但Vranken表示该项目团队于两天后反馈称，这份报告连同其它近期提交的内容需要等到下个版本发布时才能实现针对性调整。Vranken于3月1号通过个人博客公布了这项bug，而就在同一天OpenSSL发布了1.0.2g与1.0.1s两个版本。“为攻击者预留长达一个月的恶意活动周期对于保障安全显然非常不利，”他写道。
管理员与用户们强调称，他们应当能够第一时间了解与安全漏洞相关的信息，且无法坐等漫长的版本更新周期。诚然，有时候公开披露一项bug能够刺激对应企业优先审视该问题并将其修复。
而这种情况在去年的汽车黑客事件中也曾经出现，当时研究人员Charlie Miller与Chris Valasek与克莱斯勒公司投入长达九个月时间以修复安全漏洞，从而避免潜在攻击者入侵并以无线方式遥控该公司旗下的2015款切诺基车型。克莱斯勒方面在《连线》杂志发布相关报道的几天之后，即对该款车型进行了召回。
不过OpenSSL安全漏洞的情况却与之不同，因为该项目团队承认了报告内容的正确性，并表示其正在进行修复，但Evranken却强调称该团队表示必须“遵循既有日程安排与时间表。”
没有更好，也没有更糟
尽管相关问题早晚能够得到解决，不过这项bug似乎还不足以让OpenSSL团队优先着手处理。虽然Vranken并没有在博文中提供任何与其后果或者利用途径相关的信息，但Risk Based Security公司综合性漏洞数据库VulnDB已经将其收录进来，并指出其并不是那种需要放下现有工作、全力加以应对的严重缺陷。
VulnDB将该缺陷的优先级评为“高”，但其基准分数仅为7.8分，可利用性得分为8.6分，影响严重性得分为7.8分。这些分数基于通用薄弱性评分系统并纳入了其它内部分类及指标，用于确定一项已公开漏洞的利用难度以及影响严重性。
其严重程度在过去两年中OpenSSL发现的约60种漏洞当中属于“没有更好，但也没有更糟”的中等水平，Black Duck Software公司CTO Bill Ledingham表示。“研究人员就代码层面向OpenSSL报告的安全漏洞在数量上已经相当可观。”
因此对OpenSSL来说，保证相关漏洞不为外界所知晓可能会是个好主意，其意义甚至远大于此次曝出的特定漏洞本身。
未受到攻击
公开披露安全漏洞的另一大重要理由在于，实际遭遇相关攻击的管理人员能够获得消息并组织有针对性的应对措施。不过此次情况却有所不同，因为Vranken乃至VulnDB都没发现过任何由该漏洞引起的实际攻击活动。而“归功于”此次披露，攻击者们反而了解到了其具体细节并有可能加以实验，这将使得防御一方很难轻松实现系统保护。
IT部门必须等待新的OpenSSL版本，而在此之前其只能祈祷自己不要受到实际攻击的威胁。目前，在环境中使用OpenSSL的管理员们对该特定bug完全束手无策。
负责任的披露流程会耗费更长时间且相当枯燥，然而其能够真正帮助我们提升整体安全水平——因为当漏洞细节被公诸于众时，修复补丁也已经同时跟上。这才是真正令人安心的问题解决方式，也是我们应当遵循的系统/网络保护手段。即使是最精明的IT安全专家也总会被某些软件漏洞所蒙蔽，特别是当他们不清楚漏洞的具体利用方式、是否属于活动威胁或者如何将其归纳为bug报告结果的情况下。
研究人员需要考量漏洞的实际影响，且不能因为其存在潜在严重性就简单将其视为高危。如果安全报告反复向人们散布高危信息，大家反而会变得麻木甚至干脆忽略全部提醒——这显然是我们IT安全从业者所不愿看到的。
本文转自d1net（转载）