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: 我怎麼才能聯繫安全團隊?

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

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

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

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

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

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

Q: 我的套件出現了一個安全問題,我應該怎麼處理?

答:如果您在您的套件中或其他人的套件中發現了安全問題,請務必透過電子郵件地址 team@security.debian.org 聯繫安全團隊。他們跟蹤現有的安全問題、可以幫助維護者解決安全問題或自行修復問題,並且負責發送安全建議和維護 security.debian.org。

開發者參考文件列出了詳細的處理步驟。

特別重要的是,未經安全團隊事先同意,請您不要將修復上傳到除 unstable 以外的任何發行版,因為繞過安全團隊會導致混亂並增加工作量。

Q: 我嘗試下載某個安全公告中列出的套件,但出現了找不到文件錯誤。

答:每當新的缺陷修復取代了 security.debian.org 上的舊套件時,在上傳新套件時舊套件被刪除的可能性很高。所以,您可能收到找不到文件錯誤。我們希望儘可能減少分發具有已知安全漏洞的套件的時長。

請使用最新安全公告中的套件,它們透過 debian-security-announce 通信論壇分發。最好是在升級套件前簡單地執行 apt-get update

Q: 我有一個缺陷修復,我可以直接上傳到 security.debian.org 嗎?

答:不能。 security.debian.org 倉庫由安全團隊維護,必須由他們批准所有套件。您應該透過 team@security.debian.org 將補丁或適當的原始碼包發送給安全團隊。它們將由安全團隊進行審查並最終上傳,可能經過或未經修改。

開發者參考文件列出了詳細的處理步驟。

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。請同時將包含所有詳細信息和鏈接的通知也發送到 team@security.debian.org。

Q: 我應該如何協助安全團隊的工作?

答:請在向 security@debian.org 報告之前複查每個問題。如果您能夠提供補丁,還能加快工作進度。不要簡單地轉發 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)

此類漏洞在某種程度上介於本地和遠程漏洞之間,通常涉及可以透過網路提供的文件,例如從郵件附件或下載頁面得到的文件。