双重报告漏洞背后的隐患

该详细指南讨论了安全团队为何不堪重负漏洞,隐藏在重复漏洞报告中的危险以及如何使用诸如KernelCare之类的实时修补工具缓解此类漏洞。

我们知道,网络安全威胁正在不断增长,与此同时,尝试减轻威胁和相关成本的努力也在与日俱增。 但是有证据表明,缓解措施的进展不够快。

根据联合 分析 由…执行 迈克菲战略与国际研究中心,到2020年,网络犯罪的全球成本将超过 $ 1tn 首次突破-比2018年总数大幅增长50%。 这一变化率明显超过了任何可比的指标,例如GDP增长或IT支出的增长。

意识不是问题-毕竟,公司在防御网络威胁方面花费了大量资金。

取而代之的是,在本文中,我们认为网络安全参与者实际上被他们所面临的挑战所淹没。 我们指出,最近一次已知漏洞的重复报告是明显的证据。

继续阅读以了解安全团队为何不堪重负漏洞,漏洞如何影响补丁程序,以及面对漏洞和漏洞的无休止攻击,团队可以采取哪些措施来一致地进行补丁程序。

还有另一个漏洞?

去年下半年,发现并报告了Linux内核漏洞。 它被分配了一个 Common 伏特漏洞和 Exposures(CVE)编号, CVE-2020-29369,并且该漏洞已按预期进行了修补。 到目前为止,没有任何异常。

漏洞本身也没有什么不同寻常的。 在任何操作系统中,内核都必须仔细管理内存–在应用程序需要时分配(映射)内存空间,并在应用程序不再需要时正确删除分配并重新分配可用内存。

但是,这种管理内存空间的过程可能容易出现毛刺。 如果在没有必要的注意的情况下进行编码,内核内存处理过程将为网络犯罪分子提供机会。 对于CVE-2020-29369,在Linux中用于内存映射的mmap函数中发生了问题。

该漏洞的性质意味着两个不同的应用程序可以请求访问同一内存空间,从而导致内核崩溃。

如果攻击者正确地打出了自己的牌(换句话说,就是设计了一种利用),则攻击者将能够获取原本由内核保护的数据。 它可能是完全无害的数据-或更有价值的东西,例如有价值的个人数据或密码。

关于两个漏洞报告的故事

因此,我们可以看到已报告了一个典型漏洞,并按照常规过程接受了该漏洞。 但是接下来发生了一些令人不安的事情。

仅仅几个月后,就报告了完全相同的漏洞。 同样,这次分配了一个CVE号 CVE-2020-20200。 但是,很快就发现,新的漏洞警报与另一个漏洞CVE-2020-29369重复。

研究人员由于某种原因第二次“发现”该漏洞,或者其他人未能找到该漏洞的第一个实例,然后要求对他们发现的内容再次要求CVE保留。 CVE数据库的主要目的之一是避免重复报告,但是在此特定情况下,仍然请求另一个CVE。

这种情况就是所谓的 “双重报告” 不是两次报告漏洞的第一个或唯一实例。 更糟糕的是,当对漏洞的调查达到分配CVE的程度时,该漏洞将已经由众多训练有素的安全专家进行了审查。

甚至安全研究人员也可以将其混为一谈

在此双重报告示例中,很明显,如果安全研究人员在请求新的CVE编号之前充分研究了“新”漏洞,则他们应该已经意识到了现有的漏洞,或者应该已经找到了现有的CVE。

这是一个令人担忧的想法。 此内存映射漏洞位于Linux内核的核心,但是安全研究人员显然并未意识到这一点,因此将其列为双重清单。 更糟糕的是,似乎每个列表之间的间隔时间都不是十年甚至是几年:同一个漏洞的各个列表之间的间隔时间仅为几个月,一个是2020年8月,另一个是2020年11月。

安全研究人员是否疏忽大意? 不。安全研究人员完全被庞大的网络安全挑战所淹没。 这就是为什么在此示例中,Linux内核安全专家错过了有关潜在关键漏洞的现有报告。

重复报告漏洞背后的隐患

清晰的证据表明网络安全威胁正在增长,再加上甚至安全专家都将其弄错的例子表明,双重报告的影响要比乍看时要大。

这并不意味着Linux安全专家容易出错和疏忽。 它只是表明管理安全漏洞的工作变得异常困难,以至于专家们也难以跟上。

考虑一下一个拥有全面职权的典型内部技术团队-是的,包括安全性,还涵盖维护,运营和无数其他职责。

即使企业团队拥有专门的安全专家,也有可能必须在各种威胁和技术工具中应用专业知识。 即使对于大型企业而言,聘用Linux内核安全专家也将极为罕见。 而且,即使他们这样做了,正如我们所看到的,这些安全专家也可能会出错。

IT团队前途艰难

现场团队将始终在一定程度上管理安全漏洞。 例如,通过响应重大漏洞利用的消息并相应地应用补丁程序。 供应商的警告也可以推动行动,大多数优秀的IT部门将采用某种类型的修补程序,以确保按固定的间隔应用修补程序。

但是,IT团队如何才能切实地跟上不断增长的CVE,这些CVE每天都会影响到整个Linux发行版。 例如,按季度实施的修补程序确实可以提供足够的安全性吗? 是的, 修补很重要,但它是否应该以其他一切为代价来主导活动-鉴于补丁的数量,这很容易发生?

显而易见,IT团队将很难保持在不断增长的漏洞列表的前面。

制定正确的修补制度

正式制定修补程序是尝试应对CVE的第一步。 基于警报新闻报道的临时补丁不是可行的方法-漏洞太多了,而鲜为人知的漏洞很少-留下了无数隐藏的漏洞和相关的利用,构成了危险。

尽管如此,创建补丁机制的关键步骤之一是对补丁进行优先级排序。 必须迅速修补广为人知的关键漏洞,并且不得拖延,并在必要时牺牲可用性。 可以安排针对中低风险漏洞的补丁以适合技术团队的工作量,或避免可用性问题。

另一个关键步骤是建立需要修补的硬件和软件的足够完整的清单。 一些修补目标将立即显而易见,但其他目标很容易被遗漏。

在构建清单时,您还可以确定一些标准化范围-换句话说,将软件升级到相同版本或合并供应商以使补丁管理更加容易。

最后,值得将您的补丁程序制度化为正式的补丁程序策略。 修补工作很难始终如一地进行,而仅需一次失败即可打开灾难之门。 统一的修补程序可以帮助您的团队年复一年地进行修补。

修补的权衡

对于任何修补机制,通常都需要在可用性和安全性之间进行权衡。 是的,您可以以高度安全的方式进行修补-尽快应用修补程序。 但是打补丁不可避免地会影响可用性,因为打补丁通常需要重启服务器。

实际上,某些公司可能有特定的业务需求,即使出现严重的CVE,也可能阻止关闭服务或服务器以应用补丁程序,这会使服务容易受到新的攻击。

即使您可以使服务器脱机以进行维护,服务也会降级,结果,最终用户的体验也会降级。 例如,假设有一个在线零售商,有成千上万的客户在线,突然使一半服务器离线以进行维护。

然后,技术团队的工作量也将大量减少,他们不可避免地会牺牲在其他任务上花费的时间来花时间进行修补。 安全团队可能会完全被修补程序的负担所淹没。 但是,还有另一种选择。

考虑使用自动修补工具

我们已经确定了标准修补方案背后的两个关键问题:修补所需的时间和精力,以及与修补相关的中断。 值得考虑的一种解决方案是自动修补-如果需要的话,甚至更是如此。 无重启自动修补 应用补丁程序而无需重新启动服务器。

自动化的修补工具会持续监视修补程序的发布,并自动应用这些修补程序,而无需干预。 它消除了专门用于修补服务器机群的人力-修补仅在后台无缝地进行。借助自动修补,技术团队永远不会被无数的修补任务所淹没,技术团队也无需尝试预测最重要的补丁。 相反,所有补丁均无缝,均匀且一致地应用。

一些自动修补工具,例如 内核维护 可以动态地应用补丁-在机器运行时实时补丁,而无需重新启动。 实时补丁程序可限制中断,因为计算机不会脱机处理补丁程序。 如果将中断的风险降至最低,则修补一致性可能会提高。

换句话说,正确的自动修补工具可以解决公司在修补中面临的两个最大问题:所需的工作量和中断。

无论您选择哪种方式,打补丁都是至关重要的

无论贵公司为自己的补丁程序做些什么,或者无论如何安排补丁程序,都可以肯定的是,补丁程序是至关重要的。 必须应用补丁程序,但是要决定补丁的频率和补丁方式。

考虑到网络安全威胁的规模,人们强烈要求进行自动修补。 技术团队和安全研究人员越来越不知所措,自动修补程序弥合了资源和可用性问题。

总是简单地将更多的人力用于修补挑战,对于某些工作负载,这可能是唯一的选择。 然而,在大多数情况下,自动化,无需重新启动的修补程序可以在当今巨大的网络安全挑战中取得巨大胜利。

推荐阅读:

  • 使用KernelCare免费修补Raspberry Pi Linux内核!
  • 使用UChecker检测内存中过时的共享库

网络安全内核实时补丁内核维护Linux内核实时补丁安全补丁

Sidebar