LLVM 安全群組

LLVM 安全群組有以下目標

  1. 允許 LLVM 貢獻者和安全研究人員向 LLVM 社群成員披露影響 LLVM 專案的安全性相關問題。

  2. 組織針對上述問題的修復、程式碼審查和發布管理。

  3. 允許發行商在廣泛傳播漏洞或緩解缺陷之前有時間調查和部署修復程式。

  4. 確保及時通知包裝和發行基於 LLVM 的工具鏈和專案的供應商並向其發布。

  5. 透過 CVE 程序，確保及時通知編譯程式碼具有安全性敏感性的基於 LLVM 的工具鏈的使用者。

  6. 努力隨著時間的推移提高安全性，例如在修復問題後添加額外的測試、模糊測試和強化。

注意：這些目標可確保及時採取行動，在回報問題時提供披露時間，並尊重供應商/包裝者/使用者的限制。

LLVM 安全群組是私人的。它由受信任的 LLVM 貢獻者組成。在調查問題期間，其討論僅限於安全群組（以及問題報告者和關鍵專家）內部。問題公開後，該群組與該問題相關的全部討論也將公開。

如何回報安全問題？

如要回報任何 LLVM 專案中的安全問題，請使用 github 上 llvm/llvm-security-repo 儲存庫中「安全性」標籤下的 回報漏洞 功能。

我們的目標是在您首次聯繫後的兩個工作日內確認收到您的報告。如果您在此期間未收到任何回覆，您可以透過在 Discourse 論壇 上發布訊息以聯繫 LLVM 安全群組的某個人來升級問題。升級郵件列表是公開的：在上面發布訊息時，請避免討論或提及具體問題。

群組組成

安全群組成員

群組成員代表社群的廣泛橫截面，並符合以下納入標準。列表格式為 * ${全名}（${隸屬單位}）[${github 使用者名}]。如果個人的 github 使用者名不可用，則括號將為空。

  • Ahmed Bougacha（蘋果公司）[@ahmedbougacha]

  • Andy Kaylor（英特爾）[@andykaylor]

  • Artur Pilipenko（Azul Systems Inc）[]

  • Boovaragavan Dasarathan（輝達）[@mrragava]

  • Dimitry Andric（個人；FreeBSD）[@DimitryAndric]

  • Ed Maste（個人；FreeBSD）[@emaste]

  • George Burgess IV（谷歌）[@gburgessiv]

  • Josh Stone（紅帽；Rust）[@cuviper]

  • Kristof Beyls（ARM）[@kbeyls]

  • Matthew Riley（谷歌）[@mmdriley]

  • Matthew Voss（索尼）[@ormris]

  • Nikhil Gupta（輝達）[]

  • Oliver Hunt（蘋果公司）[@ojhunt]

  • Peter Smith（ARM）[@smithp35]

  • Pietro Albini（Ferrous Systems；Rust）[@pietroalbini]

  • Serge Guelton（Mozilla）[@serge-sans-paille]

  • Shayne Hiet-Block（微軟）[@GreatKeeper]

  • Tim Penge（索尼）[@tpenge]

  • Tulio Magno Quites Machado Filho（紅帽）[@tuliom]

  • Will Huhn（英特爾）[@wphuhn-intel]

  • Yvan Roux（意法半導體）[@yroux]

條件

  • LLVM 安全群組成員的被提名人應屬於以下其中一類

    • 個別貢獻者

      • 專精於修復與編譯器相關的安全性問題，或經常參與探索和解決這些問題。

      • 具有發現安全漏洞和負責任地揭露這些漏洞的過往紀錄。

      • 是編譯器專家，對了解、解決和防止未來安全漏洞有特殊興趣。

      • 在過去一年中積極為 LLVM 專案貢獻了重要的程式碼。

    • 研究人員

      • 具有發現安全漏洞和負責任地揭露這些漏洞的過往紀錄。

      • 是編譯器專家，對了解、解決和防止未來安全漏洞有特殊興趣。

    • 供應商聯絡人

      • 代表運送包含其 LLVM 副本之產品的組織或公司。由於被提名人在組織中的職位，因此需要合理地了解安全問題和揭露禁令。

  • 此外，以下條件是加入 LLVM 安全群組的必要條件，但非充分條件

    • 如果已經是 LLVM 安全群組的成員，在過去一年中至少積極參與了一個安全問題（如果有）。

    • 如果已經是 LLVM 安全群組的成員，在過去一年中積極參與了大多數成員討論。

    • 如果已經是 LLVM 安全群組的成員，在過去一年中積極參與撰寫或審閱透明度報告。

    • 受雇於公司或其他實體時，其所屬實體在 LLVM 安全群組中的成員不得超過三人。

    • 當被提名為供應商聯絡人時，其在該供應商的職位應與最初被提名時相同。

    • 被提名人應受到現有安全群組成員的信任，在保持活躍的同時對通訊保密。

提名流程

任何認為自己符合這些條件的人都可以自我提名，或者可以由第三方提名，例如現有的 LLVM 安全群組成員。提名應說明被提名人是被提名為個人、研究人員還是供應商聯絡人。它應清楚說明提名的理由。

目前，提名通常使用 GitHub 拉取請求來提出、討論和投票。 範例提名可在此處找到。使用拉取請求有助於以多種方式保持成員資格討論的公開、透明和 LLVM 開發人員易於存取。如果出於任何原因，完全公開可讀的提名似乎不恰當，您可以透過 回報漏洞 路線與安全群組聯繫，並且可以根據個人所受的限制，討論處理提名的最佳方式。

選擇新成員

如果 LLVM 安全群組成員資格的提名獲得大多數現有 LLVM 安全群組成員的支持，則該提名將在五個工作日內生效，除非現有安全群組成員提出異議。如果提出異議，LLVM 安全群組成員應討論此事並嘗試達成共識；如果未達成共識，則只有獲得 LLVM 安全群組三分之二的多數票，提名才會通過。

接受成員資格

在新 LLVM 安全群組成員資格最終確定之前，成功的被提名人應接受成員資格並同意遵守此安全政策，尤其是以下的 LLVM 安全群組成員的特權和責任。

保持成員資格有效

  • LLVM 安全群組至少每六個月會應用上述標準。成員名單將相應地進行修剪。

  • 任何安全群組成員都可以要求在接下來的五個工作天內應用標準。

  • 如果 LLVM 安全群組的成員沒有按照本政策的文字和精神行事，則其 LLVM 安全群組成員資格可以由成員的多數票撤銷，但不包括正在考慮撤銷的成員。在成員要求進行撤銷投票後，投票將開放五個工作日。

  • 緊急停權：公然無視 LLVM 安全政策的 LLVM 安全群組成員，可能會在任何兩名成員的要求下暫時停權。在這種情況下，請求的成員應通知安全群組，說明違規行為。此時，成員資格將暫時停權五個工作日，等待永久撤銷投票的結果。

  • LLVM 董事會可以從 LLVM 安全群組中移除任何成員。

透明度報告

LLVM 安全群組必須每年發布一份透明度報告。本報告的目的是透過總結過去一年公開的漏洞資訊，讓社群隨時掌握最新資訊。它應包含所有公開漏洞的清單，以及修復問題所需時間、封鎖期長度等統計數據。

透明度報告發布於 LLVM 安全群組透明度報告。

LLVM 安全群組成員的權利與責任

訪問權限

LLVM 安全群組成員將訂閱一個私人的 討論區。它將用於安全問題的技術討論，以及有關公開時間表和群組成員資格等事項的流程討論。成員可以訪問所有安全問題。

保密

LLVM 安全群組的成員應將與群組共享的 LLVM 安全問題資訊視為機密，直到公開披露為止。

  • 成員不得向非成員披露安全問題資訊，除非雙方成員受僱於同一家基於 LLVM 的產品供應商，在這種情況下，資訊可以在該組織內部基於「需要知道」的原則共享，並按照該組織通常處理機密資訊的方式處理。

  • 如果 LLVM 安全群組同意，指定成員可以與非基於 LLVM 的產品供應商共享問題，如果他們的產品存在相同的問題。應要求非 LLVM 供應商遵守問題的封鎖日期，並且不要在組織內部超出「需要知道」的人員範圍共享資訊。

  • 如果 LLVM 安全群組同意，可以邀請關鍵專家協助解決特定問題。應要求關鍵專家遵守問題的封鎖日期，並且不要共享資訊。

公開

LLVM 安全群組按照以下流程決定每個安全問題公開披露的封鎖日期。如果所有計劃發布修復程式的供應商都已這樣做，並且報告者不反對，則可以在約定的日期之前解除封鎖。

協作

LLVM 安全群組的成員預計會

  • 及時分享他們知道的任何 LLVM 漏洞。

  • 自願推動問題的解決。

  • 幫助評估傳入問題的嚴重性。

  • 幫助編寫和審查解決安全問題的修補程式。

  • 參與成員提名和移除流程。

討論媒介

用於主持 LLVM 安全群組討論的媒介具有安全敏感性。因此，它應該在能夠滿足我們安全預期的基礎架構上運行。

我們使用 GitHub 私下報告安全漏洞的機制 來進行安全討論。

  • 檔案安全問題。

  • 討論 LLVM 的安全改進。

我們還偶爾需要討論 LLVM 安全群組本身的後勤工作。

  • 提名新成員。

  • 提議移除成員。

  • 建議政策變更。

我們經常公開進行這些討論，在我們的 每月公開同步會議 和 Discourse 論壇上。對於內部或機密討論，我們也使用私人郵件清單。

流程

以下流程針對每個報告的問題在討論媒介上發生。

  • 安全問題報告者（不一定是 LLVM 貢獻者）報告問題。

  • 在兩個工作日內，安全群組的一名成員將負責推動該問題得到可接受的解決方案。這位負責人不需要在每個問題上都是同一個人。此人可以自薦。

  • 安全群組成員討論在何種情況下（如果有）問題與安全相關，並確定它是否是安全問題。

  • 協商公開披露的禁運日期，預設的最短期限為九十天。

  • 安全群組成員可以建議讓關鍵專家參與特定的問題討論。除非其他安全群組成員反對，否則可以讓關鍵專家參與。

  • 編寫和審查修補程式。

  • 將安全修補程式從最新版本回溯到舊版本並非總是有用。是否應該進行此類回溯以及回溯到多早的版本由安全群組決定。

  • 安全群組會找出如何協調 LLVM 專案本身的版本以及個別供應商的版本，以便同時修補問題。

  • 禁運日期可以由安全群組自行決定延後或提前。

  • 問題負責人從 MITRE 獲得 CVE 條目。

  • 禁運期滿後，修補程式將根據 LLVM 的一般程式碼審查流程公開發布。

  • 所有安全問題（以及提名/移除討論）在修補程式進入 LLVM 儲存庫後約十四週內公開。應採取預防措施，避免洩露報告中包含的特別敏感的數據（例如使用者名稱和密碼對）。

政策變更

LLVM 安全政策可以由 LLVM 安全群組的多數票決變更。此類變更也需要獲得 LLVM 董事會的批准。

什麼被視為安全問題？

LLVM 專案有大量的程式碼，並非所有程式碼都被視為具有安全敏感性。這一點尤其正確，因為 LLVM 的使用環境非常廣泛：威脅模型不同、不受信任的輸入不同，而且 LLVM 運行的環境也各不相同。因此，LLVM 專案認為的安全問題是其成員承諾安全維護的內容。

隨著此安全流程日趨成熟，LLVM 社群成員可以提議將程式碼庫的某一部分指定為安全敏感（或不再是安全敏感）。這需要一個理由，並且像任何 RFC 一樣需要 LLVM 社群的認可。在某些情況下，程式碼庫的某些部分可以被視為安全敏感的，但需要大量工作才能達到可管理的階段。LLVM 社群將需要決定是否要投入資源使這些程式碼部分變得安全，並隨著時間的推移維護這些安全屬性。在所有情況下，都應諮詢 LLVM 安全小組，因為他們將會處理針對這些程式碼部分提交的安全問題。

如果您不確定問題是否屬於此安全流程的範圍，請傾向於假設它屬於。安全小組可能會同意或不同意，並將在報告中解釋其理由，並透過上述流程更新本文。

LLVM 專案中目前被視為安全敏感的部分如下。請注意，此清單可能會隨著時間而改變。

  • 目前尚未定義任何內容。請不要讓這阻止您向安全小組報告您認為是安全敏感的問題。

LLVM 專案中目前被視為非安全敏感的部分如下。請注意，此清單可能會隨著時間而改變。

  • 語言前端，例如 clang，惡意輸入檔案可能會導致不良行為。例如，惡意製作的 C 或 Rust 原始程式碼檔可能會導致在 LLVM 中執行任意程式碼。這些 LLVM 部分尚未經過強化，編譯不受信任的程式碼通常還包括執行諸如 make 之類的工具程式，這些工具程式更容易執行惡意操作。