Debian 安全 FAQ

  1. 我通过 debian-security-announce 收到了 DSA,我该如何更新存在漏洞的软件包?
  2. 你的公告上的签名验证错误!
  3. Debian 如何处理安全问题?
  4. 为什么你要摆弄那个软件包的旧版本呢?
  5. 软件包的版本号表明我仍在运行受漏洞影响的版本!
  6. 我收到了一份公告,但是看上去缺少一种处理器体系架构的构建。
  7. unstable 的安全问题是怎样处理的?
  8. testing 的安全问题是怎样处理的?
  9. contribnon-free 和 \ non-free-firmware 的安全问题是怎样处理的?
  10. 公告说 unstable 在 1.2.3-1 版本中已修复,但是 unstable 此时的版本是 1.2.5-1,这是怎么回事?
  11. 为什么没有 security.debian.org 的官方镜像?
  12. 我看到了 DSA 100 和 DSA 102,此时 DSA 101 在哪里呢?
  13. 我怎么才能联系安全团队?
  14. 我猜我找到了一个安全问题,对此我该怎么办呢?
  15. 我的软件包出现了一个安全问题,我应该怎么处理?
  16. 我尝试下载某个安全公告中列出的软件包,但出现了找不到文件错误。
  17. 我有一个缺陷修复,我可以直接上传到 security.debian.org 吗?
  18. 我有一个缺陷修复,那我可以上传到 proposed-updates 吗?
  19. 我很确定我的软件包没问题,我该如何上传它们?
  20. 我应该如何协助安全团队的工作?
  21. proposed-updates 的范围是什么?
  22. 安全团队由哪些人员构成?
  23. 将会提供多长时间的安全更新?
  24. 我应该如何检查软件包的完整性?
  25. 如果在安全更新之后,某个其他的软件包出问题了怎么办?
  26. 什么是 CVE 标识符?
  27. Debian 对每个 CVE id 都会发布一个 DSA 吗?
  28. Debian 可以分配 CVE 标识符吗?
  29. Debian 有漏洞披露政策吗?
  30. 我们的漏洞管理工具显示以下漏洞还未修复(附上带有不同 CVSS 分数的 CVE 列表)。什么时候可以修复这些漏洞?
  31. local (remote)是什么意思?

Q: 我通过 debian-security-announce 收到了 DSA,我该如何更新存在漏洞的软件包?

答:正如 DSA 邮件所述,您应该更新受公告漏洞影响的软件包。您可以通过使用 apt-get upgrade 更新在您的系统上的所有软件包或使用 apt-get install package 更新单个特定软件包来做到这一点。

公告邮件中提到了存在漏洞的源软件包。因此,您应该从该源软件包更新所有二进制包。要检查二进制包的更新,请访问 https://packages.debian.org/src:source-package-name 并点击 [show ... binary packages] 中对应的您要更新的发行版。

您也可能需要重新启动服务或正在运行的进程。在软件包 debian-goodies 中包含的 checkrestart 命令可能有助于查找对应的进程。

Q: 你的公告上的签名验证错误!

答:这很可能是您的问题。在 debian-security-announce 邮件列表中有一个过滤器,它只允许发布带有安全团队中一位成员正确的签名的消息。

您的计算机上的某些电邮软件很可能会稍微更改邮件并导致签名被破坏。请确保您的软件不会进行任何 MIME 编码或解码,或者制表符/空格转换。

已知会产生该问题的软件有 fetchmail(启用了 mimedecode 选项)、formail(仅来自 procmail 3.14)以及 evolution。

Q: Debian 如何处理安全问题?

答:安全团队收到漏洞通知后,一个或多个成员将对其进行审核,并考虑其对 Debian 稳定发行版的影响(即是否受漏洞影响)。如果认为我们的系统会受漏洞影响,我们将针对该问题制造补丁。如果软件包维护者还没有与安全团队联系,那么安全团队也会与他们联系。最后,测试该补丁并准备新的软件包,然后在所有稳定版的体系架构上将其编译并上传。完成所有这些操作后,将发布安全公告。

Q: 为什么你要摆弄那个软件包的旧版本呢?

制作修复安全问题的新软件包时,最重要的准则是进行尽可能少的更改。我们的用户和开发人员都依赖于被制作的发行版的确切行为,因此,我们所进行的任何更改都可能损坏某人的系统。对于库,尤其如此:确保无论更改有多小,你都不会更改应用程序编程接口(API)或应用程序二进制接口(ABI)。

这意味着迁移到新的上游版本不是一个好的解决方案,而是应该向后移植相关的更改。通常,上游维护人员愿意在我们需要时提供帮助,不然的话 Debian 安全团队可能会提供帮助。

在某些情况下,例如当需要修改或重写大量源代码时,不可能向后移植一个安全补丁。如果发生这种情况,可能有必要迁移到新的上游版本,但这必须事先与安全团队协调。

Q: 软件包的版本号表明我仍在运行受漏洞影响的版本!

答:我们将安全补丁向后移植到稳定发行版中随附的软件包版本,而不是升级到新版本。我们这样做的原因是要确保版本变更尽可能少,以免由于安全补丁造成更改或意外损坏。您可以通过查看软件包更改日志或将其精确版本号与 Debian 安全公告中指明的版本进行比较,以此来检查您是否正在运行一个软件包的安全版本。

Q: 我收到了一份公告,但是看上去缺少一种处理器体系架构的构建。

答:通常,安全团队会发布一个包含 Debian 支持的所有体系架构的被更新的软件包的公告。但是,某些架构的构建比其它架构慢,并且可能会发生大多数架构的构建已准备就绪而有些仍不存在的情况。这些较小的架构仅占我们用户群的一小部分。根据问题的紧急程度,我们可能决定立即发布公告报。缺少的构建将在可用时立即被安装,但不会对此另行通知。当然,我们永远不会发布不存在 i386 或 amd64 构建的公告。

Q: unstable 的安全问题是怎样处理的?

答:unstable 的安全问题主要由软件包维护者处理,而不是由 Debian 安全团队处理。尽管当维护者被发现处于非活跃状态时,安全团队可能会上传高紧急程度的仅处理安全问题的修复,但安全团队始终会优先考虑对 stable 的支持。如果您想要拥有一个安全(和稳定)的服务器,强烈建议您保持在稳定版。

Q: testing 的安全问题是怎样处理的?

答:testing 的安全性得益于对 unstable 整个项目的安全努力。但是,迁移的延迟至少为两天,并且有时安全修复会被转换脚本阻止。安全团队可帮助迁移这些沿着转换脚本生成时会阻止重要安全更新的上传,但这并不总是可能的,并且可能会出现延迟。尤其是在新的稳定版发布后的几个月中,当许多新版本软件包上传到 unstable,用于 testing 的安全补丁可能会滞后。如果您想要拥有一个安全(和稳定)的服务器,强烈建议您保持在稳定版。

Q: contribnon-freenon-free-firmware 的安全问题是怎样处理的?

答:简短的回答是:不会处理。contrib、non-free 和 non-free-firmware 不是 Debian 发行版的正式组成部分,也没有发布,因此不受安全团队的支持。某些 non-free 软件包是在没有来源或没有一个允许分发修改后的版本的许可证的情况下分发的。在这些情况下,根本无法进行安全修复。如果可以解决问题,并且软件包维护者或其他人提供了正确的更新软件包,那么安全团队通常随后将对其进行处理并发布公告。

Q: 公告说 unstable 在 1.2.3-1 版本中已修复,但是 unstable 此时的版本是 1.2.5-1,这是怎么回事?

答:我们尝试列出在 unstable 中修复该问题的第一个版本。有时,维护者在此期间上传了甚至比这更新的版本。将在 unstable 的软件包版本与我们指明的版本进行比较。如果相同或更高,您应该免受此漏洞的影响。如果您想要确保这一点的话,可以使用 apt-get changelog package-name 来检查软件包变更日志,并搜索宣告该修复的条目。

Q: 为什么没有 security.debian.org 的官方镜像?

答:事实上这是存在的。有几个通过 DNS 别名实现的官方镜像。security.debian.org 的宗旨是使安全更新尽可能快且容易地获得。

鼓励使用非官方的镜像会增添通常来说没有必要的额外复杂性,而且如果这些镜像没有及时更新的话会导致各种问题。

Q: 我看到了 DSA 100 和 DSA 102,此时 DSA 101 在哪里呢?

答:几个提供方(主要是 GNU/Linux,但也包括 BSD 衍生品的提供方)协调某些漏洞的安全公告并定下特定的时间表,以便所有提供方都可以同时发布公告。做出此决定是为了不区分一些需要更多时间的提供方(例如,当提供方必须经过冗长的 QA 测试通过软件包或者必须支持多种体系架构或二进制分发时)。我们自己的安全团队也会提前准备公告。时不时的,在放置的公告能被发布之前还必须处理其它安全问题,因此会临时按编号保留一个或多个公告。

Q: 我怎么才能联系安全团队?

答:可以将安全相关的信息发送到 [email protected][email protected],这两个邮箱的信息都会被安全团队的成员读取。

如果有需要的话,可以使用 Debian 安全联系密钥(密钥 ID 0x0D59D2B15144766A14D241C66BAF400B05C3E651)对电子邮件进行加密。若想取得各个团队成员的 OpenPGP 公钥,请查看 keyring.debian.org 密钥服务器。

Q: 我猜我找到了一个安全问题,对此我该怎么办呢?

答:如果您在自己负责的一个软件包或在其他人负责的软件包找到了一个安全问题,请始终与安全团队联系。如果 Debian 安全团队确认该漏洞并且其它提供方也可能会受漏洞影响,那么他们通常也会与其它提供方联系。如果该漏洞尚未公开,他们将尝试与其它提供方协调安全公告,因此所有主要的发行版都会同步公告。

如果该漏洞已经被公开,请确保在 Debian BTS 中提交错误报告,并将其标记为security

如果您是 Debian 维护者,请参见下文

Q: 我的软件包出现了一个安全问题,我应该怎么处理?

答:如果您在您的软件包中或其他人的软件包中发现了安全问题,请务必通过电子邮件地址 [email protected] 联系安全团队。他们跟踪现有的安全问题、可以帮助维护者解决安全问题或自行修复问题,并且负责发送安全建议和维护 security.debian.org。

开发者参考文档列出了详细的处理步骤。

特别重要的是,未经安全团队事先同意,请您不要将修复上传到除 unstable 以外的任何发行版,因为绕过安全团队会导致混乱并增加工作量。

Q: 我尝试下载某个安全公告中列出的软件包,但出现了找不到文件错误。

答:每当新的缺陷修复取代了 security.debian.org 上的旧软件包时,在上传新软件包时旧软件包被删除的可能性很高。所以,您可能收到找不到文件错误。我们希望尽可能减少分发具有已知安全漏洞的软件包的时长。

请使用最新安全公告中的软件包,它们通过 debian-security-announce 邮件列表分发。最好是在升级软件包前简单地执行 apt-get update

Q: 我有一个缺陷修复,我可以直接上传到 security.debian.org 吗?

答:不能。 security.debian.org 仓库由安全团队维护,必须由他们批准所有软件包。您应该通过 [email protected] 将补丁或适当的源代码包发送给安全团队。它们将由安全团队进行审查并最终上传,可能经过或未经修改。

开发者参考文档列出了详细的处理步骤。

Q: 我有一个缺陷修复,那我可以上传到 proposed-updates 吗?

答:从技术上讲,您可以。但是,您不应该这样做,因为这会严重干扰安全团队的工作。来自 security.debian.org 的软件包会被自动复制到 proposed-updates 目录中。如果已将具有相同或更高版本号的软件包上传到仓库中,则仓库系统将拒绝此安全更新。这样一来,stable 发行版最终将不会对此包进行安全更新,除非 proposed-updates 目录中的错误的包被拒绝。请联系安全团队、提供漏洞的所有详细信息,并在您的邮件中添加源码文件(即 diff.gz 和 dsc 文件)作为附件。

开发者参考文档列出了详细的处理步骤。

Q: 我很确定我的软件包没问题,我该如何上传它们?

答:如果您非常确定您的软件包不会让任何东西出问题、版本是正常的(即大于 stable,小于 testing 和 unstable)、您没有改变包的行为(除了修复对应的安全问题)、您已针对正确的发行版进行编译(即 oldstable-securitystable-security)、如果包是新上传到 security.debian.org 上的那么它已经包含了源代码、您可以确认您的补丁相对于最新版本是干净的并且只涉及相应的安全问题(检查 interdiff -z 和两个 .diff.gz 文件)、您至少已经对补丁进行了三次校对、debdiff 没有显示任何更改,那么您可以将文件直接上传到 security.debian.org 上的 incoming 目录 ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue。请同时将包含所有详细信息和链接的通知也发送到 [email protected]

Q: 我应该如何协助安全团队的工作?

答:请在向 [email protected] 报告之前复查每个问题。如果您能够提供补丁,还能加快工作进度。不要简单地转发 bugtraq 邮件,因为我们已经收到了它们——但可以向我们提供有关 bugtraq 上报告的问题的额外信息。

开始安全工作的一个不错的方式是帮助 Debian Security Tracker(指引)。

Q: proposed-updates 的范围是什么?

答:该目录包含被提议进入下一个 Debian stable 修订版本的软件包。 每当维护者为 stable 发行版上传软件包时,它们会先出现在 proposed-updates 目录中。 由于 stable 需要稳定,因此不会进行自动更新。 安全团队会将其公告中提到的已修复的软件包上传到 stable,但它们将首先被上传到 proposed-updates 中。 每隔几个月, 稳定版发布管理员会检查 proposed-updates 中的软件包列表,并讨论一个软件包是否适合稳定版。 它会被编译成 stable 的另一个修订版本(例如 2.2r3 或 2.2r4)。不适合的软件包也可能会被拒绝并从 proposed-updates 中删除。

请注意,维护者(不是安全团队)在 proposed-updates/ 目录中上传的软件包不受安全团队支持。

Q: 安全团队由哪些人员构成?

答:Debian 安全团队包括几名官员和秘书。由安全团队本身来任命人员加入团队。

Q: 将会提供多长时间的安全更新?

答:安全团队会在 stable 发行版发布后的三年内提供支持。不可能支持三个发行版; 同时支持两个已经够难的了。

Q: 我应该如何检查软件包的完整性?

答:这一过程涉及到检查 Release 文件的签名是否和仓库使用的公钥匹配。Release 文件包含了 Packages 和 Sources 文件的校验和,而 Packages 和 Sources 文件又包含了二进制包和源码包的校验和。检查软件包完整性的详细步骤可以在 Debian 安全手册中找到。

Q: 如果在安全更新之后,某个其他的软件包出问题了怎么办?

答:首先,您应该弄清楚软件包出问题的原因以及它为何与安全更新有关。如果问题严重,请联系安全团队;如果不严重,请联系稳定版发布管理员。我们讨论的是某个随机的软件包在另一个软件包进行安全更新以后就无法工作的问题。如果您无法弄清楚出了什么问题但需要修复,请与安全团队联系。不过,可能最后还是会让您找稳定版发布管理员。

Q: 什么是 CVE 标识符?

答:Common Vulnerabilities and Exposures 项目为特定安全漏洞分配唯一名称(称为 CVE 标识符),以让独一无二地指代特定问题变得更容易。更多信息参见维基百科

Q: Debian 对每个 CVE id 都会发布一个 DSA 吗?

答:Debian 安全团队跟踪每个发布的 CVE 标识符,将其关联到相关的 Debian 软件包并评估其在 Debian 环境中的影响——一个问题被分配了 CVE id 并不一定意味着该问题对 Debian 系统是一个严重的威胁。这一信息在 Debian Security Tracker 中进行跟踪,对于我们认为严重的问题,将发布 Debian 安全公告。

不符合发布 DSA 条件的低影响问题可以在 Debian 的下一个版本、当前 stable 或 oldstable 发行版的小版本中修复,或者被包含在针对更严重的漏洞发布的 DSA 中。

Q: Debian 可以分配 CVE 标识符吗?

答:Debian 是一个 CVE 编号机构,可以分配标识符,但根据 CVE 政策,只能分配给尚未公开的问题。如果您在 Debian 中的软件中发现了一个未公开的安全漏洞并希望为它获得一个标识符,请联系 Debian 安全团队。 对于漏洞已经公开的情况,我们建议遵循 CVE OpenSource Request HOWTO 中描述的程序。

Q: Debian 有漏洞披露政策吗?

答:作为参与 CVE 项目的一部分,Debian 已经发布了一份漏洞披露政策

Q: 我们的漏洞管理工具显示以下漏洞还未修复(附上带有不同 CVSS 分数的 CVE 列表)。什么时候可以修复这些漏洞?

答:Debian 不提供 CVSS 分数,也不会使用第三方来源的 CVSS 分数来对安全漏洞进行分类。

您可以在 Debian Security Tracker 中通过 ID 查询各个 CVE ID 的状态。

Notes部分会提供一些额外信息,例如,某个安全漏洞没有必要发布 Debian 安全更新,但可能会在将来的小版本更新中修复。

计划发布安全更新的软件包列表可以在需要 DSA 的软件包列表中找到。

如果您在分类数据中发现了错误,欢迎您报告它。但是,Debian 安全团队一般不会对索取更详细的信息的请求进行回复,您应当联系您的漏洞管理工具的供应商索取这些信息,毕竟是他们就安全漏洞向您发出了警报,而不是 Debian。

已弃用的 Debian 安全 FAQ

Q: local (remote)是什么意思?

DSA 邮件中的 Problem type 字段自 2014 年 4 月起已经不再使用。
答:一些公告涵盖了无法通过是否可以本地/远程利用这一经典方式进行归类的漏洞。某些漏洞无法远程利用,即无法和监听网络端口的守护进程相对应。如果这些漏洞能被可以通过网络提供的特殊文件利用,但易受攻击的服务没有永久连接到网络,我们在这种情况下说漏洞的类型是local (remote)

此类漏洞在某种程度上介于本地和远程漏洞之间,通常涉及可以通过网络提供的文件,例如从邮件附件或下载页面得到的文件。