☰

当无法通过 apt-get 获取新版本时，如何补救/修复 Ubuntu zlib 包中的 CVE？

tag-icon • tag-icon security apt
当无法通过 apt-get 获取新版本时，如何补救/修复 Ubuntu zlib 包中的 CVE？

我有多个运行 Ubuntu 14.04.2 的云堆栈，我需要修复我在库中接触到的 CVE zlib（具体来说zlib1g和）zlib1g-dev。最终我需要将这些系统迁移到较新版本的 Ubuntu，然而，在我解决升级阻碍之前，我需要缓解现有的 CVE。

  • 升级系统包的最佳实践是什么？
  • 我应该担心什么问题/如何测试功能回归？

我目前正在测试的是添加来自较新版本的 Ubuntu 的源（例如artful）：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.d/artful.list
sudo vim /etc/apt/sources.list.d/artful.list  # replace "trusty" with "zesty"
sudo apt-get update

将所有包固定到trusty：

$ cat /etc/apt/preferences

Package: *
Pin: release n=trusty
Pin-Priority: 900

Package: *
Pin: release o=Ubuntu
Pin-Priority: -10

然后使用以下命令升级特定软件包：

apt-get install --only-upgrade <package> -t zesty

我需要升级的软件包：zlib1g/zlib1g-dev

升级系统软件包无法让我获得已解决 CVE 问题的 zlib1g 版本。我需要的版本 >=1:1.2.8.dfsg-4最接近的版本可能1:1.2.11.dfsg-0ubuntu1来自zesty。请参阅：

$ dpkg -s zlib1g | grep Version:
Version: 1:1.2.8.dfsg-1ubuntu1

$ sudo apt-get update && apt-get upgrade

$ dpkg -s zlib1g | grep Version:
Version: 1:1.2.8.dfsg-1ubuntu1

内容/etc/apt/sources.list：

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.

deb http://archive.ubuntu.com/ubuntu/ trusty main restricted
deb-src http://archive.ubuntu.com/ubuntu/ trusty main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted

## Uncomment the following two lines to add software from the 'universe'
## repository.
## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://archive.ubuntu.com/ubuntu/ trusty universe
deb-src http://archive.ubuntu.com/ubuntu/ trusty universe
deb http://archive.ubuntu.com/ubuntu/ trusty-updates universe
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates universe

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
# deb http://archive.ubuntu.com/ubuntu/ trusty-backports main restricted
# deb-src http://archive.ubuntu.com/ubuntu/ trusty-backports main restricted

deb http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
deb http://archive.ubuntu.com/ubuntu/ trusty-security universe
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security universe
# deb http://archive.ubuntu.com/ubuntu/ trusty-security multiverse
# deb-src http://archive.ubuntu.com/ubuntu/ trusty-security multiverse

答案1

如果您没有关于您想要修补的内容的更多细节，以及该软件在给定版本的 Ubuntu 存储库中的哪个位置，我们就不可能给您一个足够狭窄的完整答案。

但是，我会尝试向您概述如何“修补” Ubuntu 软件包中的安全问题。

$RELEASE-security通过存储库，在 Main 中提供软件包，在 Universe 中提供社区贡献的补丁

对于用户在 Universe 软件包中提交给安全团队考虑的安全补丁，以及安全团队自己在 Ubuntu Main 软件包中提交的安全补丁，一旦发布，它们就可以从$RELEASE-security存储库（例如xenial-security）和$RELEASE-updates存储库中获得。这样，您只需简单地执行sudo apt-get update && sudo apt-get dist-upgrade并获取所有补丁即可。

跟踪CVE 追踪将让您知道 CVE 是否已在 Ubuntu 中发布修复程序，以及安全团队对 CVE 优先级别的确定以及需要多快解决（无论 CVE 严重性如何，默认值为“中”）。

存储库中的软件包未更新

我们这里有两个问题。首先，Universe 软件包只有在社区提供补丁供安全团队查看和审查时才会获得补丁。其次，因此大量软件包未得到更新。

对于这些问题，您有两种解决方案：要么自己使用补丁重建软件包，要么等待更新进入存储库（或等待某人向安全团队提交补丁）。

对于第一个解决方案，你必须遵循包装指南从步骤 1 到步骤 3.9，然后按照第 6 节中详述的步骤（如果您想将它们提交到存储库）并在您的系统上本地构建修补程序包并安装它们。

实际过程如下非常非常根据包的不同而复杂，因此无法在这里回答。

定制编译软件

您唯一的希望就是自己给软件打补丁，然后重新编译并安装。这适用于软件未包含在存储库中的任何情况，或者您安装了最初编译过的东西的情况。这个过程千差万别，所以这里无法回答。

答案2

如果你有一个必须修复的 CVE，而你使用的版本的官方存储库中没有修复它，你应该不是要做的就是从任意未来版本下载并安装软件包。此类软件包可能安装正常，但不能保证现有的其他现有软件能够与它们互操作。 ABI 或 API 可能已更改，可能是显著的，也可能不是。细微的变化可能足以引发难以调试的错误。（如果库未按预期加载，命令行应用程序可能会抛出文件未找到错误，即使命令的文件显然存在！）

我的建议是：

  1. 检查您正在使用的版本是否有可用的补丁，无论是在其他地方的 CVE 报告中，还是从上游。
  2. 如果是，则下载并修改相关包的源包：如何获取和修改通过 apt-get 安装的软件包的源代码？
    • 用于quilt应用补丁（见Debian 维基， 或者这个 Debian 指南）。
    • 我建议您只增加版本号中最低有效部分（最后一个之后的部分-）——当然不要增加第一个之前的部分:，即纪元号。
  3. 安装这样构建的包。

这更有可能保持与操作系统其他组件的兼容性（只要修复本身不会破坏某些东西），同时仍允许您在更新到达您版本的存储库时进行升级。这样，您还可以保证您想要修复的特定 CVE 已尽可能地得到修复，而对于来自某个任意未来版本的软件包，情况可能并非如此。

答案3

以下是我第一次创业时所做的事情。

  1. 我使用自定义基础 Docker 镜像将应用程序打包成微服务。微服务全部基于 Node.js，因此这是基础
  2. 我使用 Kubernetes / Docker Compose 将这些服务部署到 stage/prod 环境中
  3. 我将这些 Docker 镜像存储在 cloud.docker.com 上，它有一个很好的 Docker 镜像扫描器，可以通过查看镜像内部来查找相关的 CVE。

这就是我找到相关 CVE 的方法。然后

  1. 我阅读了 CVE 以查看哪些已应用。这 4 个 CVE 如下所示：
    • zlib 1.2.8 中的 inftrees.c 可能允许上下文相关的攻击者利用不正确的指针算法造成未指定的影响。
    • zlib 1.2.8 中的 inffast.c 可能允许上下文相关的攻击者利用不正确的指针算法造成未指定的影响。
    • zlib 1.2.8 中 inflate.c 中的 inflateMark 函数可能允许上下文相关的攻击者通过涉及负整数左移的向量造成未指定的影响。
    • zlib 1.2.8 中的 crc32.c 中的 crc32_big 函数可能允许上下文相关的攻击者通过涉及大端 CRC 计算的向量造成未指定的影响。

对我来说，“未指定”和“上下文相关”意味着这是一次相当理论化的攻击。这意味着有很多钱的坏人想要闯入你- 与那些想打压他人的普通坏人不同。只有您知道将资源投入到哪里最好。

就我而言，有一些 Chrome CVE（Chrome 是 Node.js 的基础）不适用于我的用例，所以我忽略了它们，等待上游修复。有时有些问题需要立即修复，因此：

  1. 我更新了 Docker 镜像。由于所有微服务都是从自定义基础 Docker 镜像开始的，因此我可以相对快速地推出 Node 和 OS 更新。
  2. 部署到阶段，在阶段进行烟雾测试，然后部署到生产。

我在这里对其他一些答案投了赞成票——希望你能找到你想要的东西。

相关内容