我正在运行几台 Ubuntu 18.04 机器,它们都需要 OpenSSL。
近日,OpenSSL报告了一个安全问题:https://www.openssl.org/news/secadv/20200421.txt(CVE-2020-1967)。
我确实通过 Ubuntu 标准软件包安装了 OpenSSL,这里没有自定义软件包源,我也没有自己编译它。因此,由于情况如此,并且我使用的是当前维护的 LTS 发行版(如上所述为 18.04),我假设运行apt update
并apt upgrade
足以获取最新更新并免受该漏洞的影响。但事实并非如此。显然,情况更加复杂。
根据https://launchpad.net/ubuntu/+source/opensslUbuntu 有一个 OpenSSL 软件包版本,可以对上述 CVE-2020-1967 做出反应。但是,它的版本名称中仍然包含 1.1.1f,而修复该问题的 OpenSSL 版本实际上是 1.1.1g(根据他们的建议)。而且,更重要的是:该软件包仅适用于 Focal Fossa (20.04)。
因此,我想借此机会了解一些有关 Ubuntu 内部以及软件包版本如何进入我的计算机的知识:
- 为什么只为较新的 LTS 发行版创建新的软件包,而旧的软件包仍然易受攻击?
- 这个过程通常是怎样进行的?
- 从漏洞公开宣布到修补程序包可通过 获得的平均时间是多久
apt upgrade
?
答案1
为什么只为较新的 LTS 发行版创建新的软件包,而旧的软件包仍然易受攻击?只是错误的,让我们向你展示如何自己确定这一点:
首先,让我们看一下Ubuntu CVE 跟踪器。
输入你的 CVE 编号,你将看到:
- Ubuntu 安全团队已经解决了这个问题。
- 一些 Ubuntu 版本需要新的软件包,其他版本则不需要。
- 跟踪器包含修复后的精确软件包版本。
其次,很多人对 Debian/Ubuntu 的概念感到困惑快照版本模型。在此模型下,单个版本(如 19.10 或 20.04)中的软件不会随着新版本的发布而增加……甚至大多数安全版本也是如此。
- 例外:也存在一些例外,例如网络浏览器,它总是会在旧版本上获取最新版本。
然而,“不增加”并不意味着“不修复”。许多软件包在发布后都会获得安全补丁没有升级到新版本。我们再说一遍:用户鼓励更新到较新的软件包因为大多数用户没有技能或耐心来修补和重新编译软件包。发行版然而,像 Ubuntu 这样的公司确实有这种技能和耐心的工程师。
- 这是风险管理:较新的软件包可能会引入错误,并且尚未在发布时进行测试,因此大多数软件包都经过修补。
最后,让我们以这两个元素为基础,看一下 CVE-2020-1967 中的 OpenSSL 示例:
- Ubuntu 安全团队评估了 Ubuntu 六个不同版本中的漏洞。其中一个版本中存在该漏洞。
- 上游版本(针对用户)是 1.1.1g 版本
- 安全团队在 20.04 的软件包 1.1.1f 中修补了该漏洞。由于他们添加了补丁而不是合并新的上游版本,因此他们不能再声称它是 1.1.1f,也不是 1.1.1g。它是其他东西,所以它被称为 1.1.1f-1ubuntu2。请注意,“ubuntu2”中的“2”表示这是第三该软件包的补丁程序,因为它来自上游。
- 这种补丁标签方案并非偶然——它是经过精心设计的,因此您可以一眼看出有多少补丁来自 Debian,有多少补丁来自 Ubuntu。此外,它仍然按字母数字排序,因此 apt 始终可以正确识别要安装的最高版本。
- 最后,经过审查和测试,修补后的软件包
openssl 1.1.1f-1ubuntu2
在发布前上传到 20.04 (Focal)。如果补丁是在发布后进行的,它将位于 focal-security 存储库中。这就是为什么将 -security 存储库保留在您的源中并保持无人值守升级处于活动状态很重要的原因之一。