Debian security FAQ

  1. 我透過 debian-security-announce 收到了 DSA,我該如何更新存在漏洞的套件?
  2. 你的公告上的簽名驗證錯誤!
  3. Debian 如何處理安全問題?
  4. 為什麼你要擺弄那個套件的舊版本呢?
  5. 套件的版本號表明我仍在運行受漏洞影響的版本!
  6. 我收到了一份公告,但是看上去缺少一種處理器體系架構的構建。
  7. unstable 的安全問題是怎樣處理的?
  8. testing 的安全問題是怎樣處理的?
  9. contribnon-free 的安全問題是怎樣處理的?
  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. What am I supposed to do with a security problem in one of my packages?
  16. I tried to download a package listed in one of the security advisories, but I got a `file not found' error.
  17. I've got a bugfix, can I upload to security.debian.org directly?
  18. I've got a bugfix, can I upload to proposed-updates instead?
  19. I'm pretty sure my packages are fine, how can I upload them?
  20. How can I help with security?
  21. What is the scope of proposed-updates?
  22. How is the security team composed?
  23. How long will security updates be provided?
  24. How can I check the integrity of packages?
  25. What to do if a random package breaks after a security update?
  26. What is a CVE identifier?
  27. Does Debian issue a DSA for every CVE id?
  28. Can Debian assign CVE identifiers?
  29. Does Debian have a vulnerability disclosure policy?
  30. What does local (remote) mean?

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-free 的安全問題是怎樣處理的?

答:簡短的回答是:不會處理。contrib 和 non-free 不是 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: 我怎麼才能聯繫安全團隊?

答:可以將安全相關的信息發送到 security@debian.org 或 team@security.debian.org,這兩個郵箱的信息都會被安全團隊的成員讀取。

如果有需要的話,可以使用 Debian 安全聯繫密鑰(密鑰 ID 0x0D59D2B15144766A14D241C66BAF400B05C3E651)對電子郵件進行加密。若想取得各個團隊成員的 PGP/GPG 公鑰,請查看 keyring.debian.org 密鑰伺服器。

Q: 我猜我找到了一個安全問題,對此我該怎麼辦呢?

答:如果您在自己負責的一個套件或在其他人負責的套件找到了一個安全問題,請始終與安全團隊聯繫。如果 Debian 安全團隊確認該漏洞並且其它提供方也可能會受漏洞影響,那麼他們通常也會與其它提供方聯繫。如果該漏洞尚未公開,他們將嘗試與其它提供方協調安全公告,因此所有主要的發行版都會同步公告。

如果該漏洞已經被公開,請確保在 Debian BTS 中提交錯誤報告,並將其標記為 security

如果您是 Debian 維護者,請參見下文

Q: What am I supposed to do with a security problem in one of my packages?

A: If you learn of a security problem, either in your package or someone else's please always contact the security team via email at team@security.debian.org. They keep track of outstanding security problems, can help maintainers with security problems or fix problems on their own, are responsible for sending out security advisories and maintaining security.debian.org.

The Developer's Reference has complete instructions on what to do.

It's particularly important that you don't upload to any other distribution other than unstable without prior agreement by the security team, because bypassing them will cause confusion and more work.

Q: I tried to download a package listed in one of the security advisories, but I got a `file not found' error.

A: Whenever a newer bugfix supersedes an older package on security.debian.org, chances are high that the old package will be removed by the time the new one gets installed. Hence, you'll get this `file not found' error. We don't want to distribute packages with known security bugs longer than absolutely necessary.

Please use the packages from the latest security advisories, which are distributed through the debian-security-announce mailing list. It's best to simply run apt-get update before upgrading the package.

Q: I've got a bugfix, can I upload to security.debian.org directly?

A: No, you can't. The archive at security.debian.org is maintained by the security team, who have to approve all packages. You should instead send patches or proper source packages to the security team via team@security.debian.org. They will be reviewed by the security team and eventually uploaded, either with or without modifications.

The Developer's Reference has complete instructions on what to do.

Q: I've got a bugfix, can I upload to proposed-updates instead?

A: Technically speaking, you can. However, you should not do this, since this interferes badly with the work of the security team. Packages from security.debian.org will be copied into the proposed-updates directory automatically. If a package with the same or a higher version number is already installed into the archive, the security update will be rejected by the archive system. That way, the stable distribution will end up without a security update for this package instead, unless the wrong packages in the proposed-updates directory were rejected. Please contact the security team instead and include all details of the vulnerability and attach the source files (i.e. diff.gz and dsc files) to your mail.

The Developer's Reference has complete instructions on what to do.

Q: I'm pretty sure my packages are fine, how can I upload them?

A: If you are very sure that your packages don't break anything, that the version is sane (i.e. greater than the version in stable and less than the version in testing/unstable), that you didn't change the behaviour of the package, despite the corresponding security problem, that you compiled it for the correct distribution (that is oldstable-security or stable-security), that the package contains the original source if the package is new on security.debian.org, that you can confirm the patch against the most recent version is clean and only touches the corresponding security problem (check with interdiff -z and both .diff.gz files), that you have proofread the patch at least thrice, and that debdiff doesn't display any changes, you may upload the files into the incoming directory ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue on the security.debian.org directly. Please send a notification with all details and links to team@security.debian.org as well.

Q: How can I help with security?

A: Please review each problem before reporting it to security@debian.org. If you are able to provide patches, that would speed up the process. Do not simply forward bugtraq mails, because we already receive them — but do provide us with additional information about things reported on bugtraq.

A good way to get started with security work is helping out on the Debian Security Tracker (instructions).

Q: What is the scope of proposed-updates?

A: This directory contains packages which are proposed to enter the next revision of Debian stable. Whenever packages are uploaded by a maintainer for the stable distribution, they end up in the proposed-updates directory. Since stable is meant to be stable, no automatic updates are made. The security team will upload fixed packages mentioned in their advisories to stable, however they will be placed in proposed-updates first. Every couple of months the Stable Release Manager checks the list of packages in proposed-updates and discusses whether a package is suited for stable or not. This is compiled into another revision of stable (e.g. 2.2r3 or 2.2r4). Packages that don't fit will probably be rejected and dropped from proposed-updates as well.

Note that the packages uploaded by maintainers (not by the security team) in the proposed-updates/ directory are not supported by the security team.

Q: How is the security team composed?

A: The Debian security team consists of several officers and secretaries. The security team itself appoints people to join the team.

Q: How long will security updates be provided?

A: The security team tries to support a stable distribution for about one year after the next stable distribution has been released, except when another stable distribution is released within this year. It is not possible to support three distributions; supporting two simultaneously is already difficult enough.

Q: How can I check the integrity of packages?

A: This process involve checking the Release file signature against the public key used for the archive. The Release file contains the checksums of Packages and Sources files, which contain checksums of binary and source packages. Detailed instruction on how to check packages integrity can be found in the Debian Securing Manual.

Q: What to do if a random package breaks after a security update?

A: First of all, you should figure out why the package breaks and how it is connected to the security update, then contact the security team if it is serious or the stable release manager if it is less serious. We're talking about random packages that break after a security update of a different package. If you can't figure out what's going wrong but have a correction, talk to the security team as well. You may be redirected to the stable release manager though.

Q: What is a CVE identifier?

A: The Common Vulnerabilities and Exposures project assignes unique names, called CVE identifiers, to specific security vulnerabilities, to make it easier to uniquely refer to a specific issue. More information can be found at Wikipedia.

Q: Does Debian issue a DSA for every CVE id?

A: The Debian security team keeps track of every issued CVE identifier, connect it to the relevant Debian package and assess its impact in a Debian context - the fact that something is assigned a CVE id does not necessarily imply that the issue is a serious threat to a Debian system. This information is tracked in the Debian Security Tracker and for the issues that are considered serious a Debian Security Advisory will be issued.

Low-impact issues not qualifying for a DSA can be fixed in the next release of Debian, in a point release of the current stable or oldstable distributions, or are included in a DSA when that is being issued for a more serious vulnerability.

Q: Can Debian assign CVE identifiers?

A: Debian is a CVE Numbering Authority and can assign ids, but per CVE policy only to yet-undisclosed issues. If you have an undisclosed security vulnerability for software in Debian and would like to get an identifier for it, contact the Debian Security Team. For cases where the vulnerability is already public, we advise to follow the procedure detailed in the CVE OpenSource Request HOWTO.

Q: Does Debian have a vulnerability disclosure policy?

A: Debian has published a vulnerability disclosure policy as part of its participation in the CVE program.

Deprecated Debian security FAQ

Q: What does local (remote) mean?

The field Problem type in DSA mails is not used since April 2014.
A: Some advisories cover vulnerabilities that cannot be identified with the classic scheme of local and remote exploitability. Some vulnerabilities cannot be exploited from remote, i.e. don't correspond to a daemon listening to a network port. If they can be exploited by special files that could be provided via the network while the vulnerable service is not permanently connected with the network, we write local (remote) in such cases.

Such vulnerabilities are somewhat between local and remote vulnerabilities and often cover archives that could be provided through the network, e.g. as mail attachment or from a download page.