驅動程式的威脅建模

驅動程式寫入器和架構設計人員應該讓威脅模型化成為任何驅動程序設計程式不可或缺的一部分。 本主題提供建立 Windows 驅動程式威脅模型的指導方針。

安全性應該是任何驅動程式的基本設計點。 任何成功的產品都是目標。 如果您要撰寫適用於 Windows 的驅動程式，您必須假設有時候某個地方有人會嘗試使用您的驅動程式來危害系統安全性。

設計安全驅動程式牽涉到：

• 識別司機可能容易受到攻擊的點。
• 分析可能在每個這類點發動的攻擊類型。
• 確保驅動程序的設計方式是為了挫敗這類攻擊。

威脅模型化是這些重要設計工作的結構化方法。 威脅模型是分類和分析資產威脅的方法。 從驅動程式寫入器的觀點來看，資產是計算機或網路上的硬體、軟體和數據。

威脅模型會回答下列問題：

• 哪些資產需要保護？
• 資產易受攻擊的威脅為何？
• 每個威脅有多重要或可能？
• 如何減輕威脅？

威脅模型化是軟體設計的一個重要部分，因為它可確保產品內建安全性，而不是做為事後解決。 良好的威脅模型有助於在設計過程中發現並預防漏洞，從而避免日後需要高成本的修補程式，也避免對組織聲譽造成潛在損害。

本節將威脅模型化原則套用至驅動程序設計，並提供驅動程式可能易感的威脅範例。 如需軟體設計威脅模型化的完整描述，請參閱這些資源。

• Microsoft SDL 網站：

  https://www.microsoft.com/sdl

• 簡化Microsoft SDL 的實作：

  下載白皮書

• 此部落格文章說明如何下載一份免費的安全性開發生命週期：SDL，由 Michael Howard 和 Steve Lipner 所著。

  https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

建立驅動程序的威脅模型

建立威脅模型需要徹底瞭解驅動程序的設計、可能暴露驅動程式的威脅類型，以及利用特定威脅的安全性攻擊後果。 為驅動程式建立威脅模型之後，您可以判斷如何減輕潛在威脅。

威脅模型化在驅動程式設計期間以有組織、結構化的方式執行時最為有效，而不是在編碼期間隨意執行。 結構化方法會增加您在設計中探索弱點的可能性，藉此協助確保模型全面。

組織威脅模型化工作的其中一種方式是遵循下列步驟：

1. 建立結構化圖表，顯示透過驅動程序的數據流。 包含驅動程式執行的所有可能工作，以及驅動程式所有輸入和輸出的來源和目的地。 正式的數據流圖或類似的結構化圖表可協助您透過驅動程式分析數據路徑，並識別驅動程式的外部介面、界限和互動。
2. 根據數據流程圖分析潛在的安全性威脅。
3. 評估您在上一個步驟中識別的威脅，並判斷如何減輕威脅。

建立數據流圖

數據流程圖以概念形式顯示驅動程式與其互動的外部實體之間的數據流，通常是作系統、用戶進程和裝置。 正式的數據流圖會使用下列符號：

下圖顯示假設核心模式 Windows 驅動程式模型 （WDM） 驅動程式的範例數據流程圖。 不論您特定類型的驅動程式架構為何，概念模型都相同：顯示所有數據路徑，並識別進入或結束驅動程式的每個數據源。

注意 上圖顯示直接在用戶進程與驅動程式之間流動的數據，並省略任何中繼驅動程式。 不過，實際上，所有要求都會通過 I/O 管理器，而且可能會在到達特定驅動程序之前經過一個或多個較高層級的驅動程序。 此圖會省略這些中繼步驟，強調數據的原始來源和提供數據之線程內容的重要性。 核心模式驅動程式必須驗證源自使用者模式的數據。

資訊會因為來自作業系統的要求、來自使用者程序的要求，或來自裝置的要求（通常是中斷）而進入驅動程式。

上圖中的驅動程式會從作系統接收數種要求類型的數據：

• 要求透過呼叫 DriverEntry、 DriverUnload 和 AddDevice 例程來執行驅動程式及其裝置的系統管理工作
• 隨插即用要求 （IRP_MJ_PNP）
• 電源管理要求（IRP_MJ_POWER）
• 內部裝置 I/O 控制要求 （IRP_MJ_INTERNAL_DEVICE_CONTROL）

為了回應這些要求，數據會從驅動程式流回作系統作為狀態資訊。 此圖中的驅動程式會從下列類型的要求中接收使用者進程的資料：

• 建立、讀取和寫入要求（IRP_MJ_CREATE、IRP_MJ_READ或IRP_MJ_WRITE）
• 公用裝置 I/O 控制要求 （IRP_MJ_DEVICE_ CONTROL）

為了回應這些要求，輸出數據和狀態資訊會從驅動程式傳回用戶進程。

最後，驅動程式會因為裝置 I/O 作業或使用者動作（例如在CD磁碟驅動器上開啟匣）而從裝置接收數據，以變更裝置狀態。 同樣地，驅動程序的數據會在 I/O 作業期間流向裝置，並變更裝置狀態。

上圖以廣泛的概念層級呈現驅動程式的資料流。 每個圓形都代表相對大型的工作，而且缺乏詳細數據。 在某些情況下，例如範例的一層圖表就足以了解數據源和路徑。 如果您的驅動程式處理來自不同來源的許多不同類型的 I/O 要求，您可能需要建立一或多個其他圖表，以顯示更多詳細數據。 例如，標示為「處理 I/O 要求」的圓形可能會展開成個別圖表，如下圖所示。

第二個圖表顯示第一個圖表中每個 I/O 要求類型的個別工作。 （為了簡單起見，已省略裝置的數據路徑。

圖表中顯示的外部實體和輸入和輸出類型可能會根據裝置的類型而有所不同。 例如，Windows 提供許多常見裝置類型的類別驅動程式。 系統提供的類別驅動程式可與廠商提供的迷你驅動程式搭配使用，這通常是包含一組回呼例程的動態連結庫 （DLL）。 使用者 I/O 要求會導向至類別驅動程式，然後呼叫minidriver中的例程來執行特定工作。 minidriver 通常不會收到整個 I/O 要求封包作為輸入;相反地，每個回呼例程只會接收其特定工作所需的數據。

當您建立數據流圖時，請記住驅動程式要求的各種來源。 在使用者計算機上執行的任何程式代碼都可以產生驅動程式的 I/O 要求，從Microsoft Office 等知名應用程式到可能可疑來源的免費軟體、共用軟體及 Web 下載。 視您的特定裝置而定，您可能也需要考慮公司隨附的媒體編解碼器或第三方篩選器，以支援其裝置。 可能的數據來源包括：

• IRP_MJ_XXX驅動程序處理的要求
• 驅動程式定義或處理的IOCTL
• 驅動程式呼叫的 API
• 回呼例程
• 驅動程序公開的任何其他介面
• 驅動程式讀取或寫入的檔案，包括安裝期間所使用的檔案
• 驅動程式讀取或寫入的登錄機碼
• 組態屬性頁，以及驅動程式取用之使用者所提供的任何其他資訊

您的模型也應該涵蓋驅動程式安裝和更新程式。 包含驅動程式安裝期間讀取或寫入的所有檔案、目錄和登錄項目。 也請考慮在裝置安裝程式、共同安裝程式和屬性頁中公開的介面。

驅動程式與外部實體交換數據的任何時間點都可能容易受到攻擊。

分析潛在威脅

在您識別驅動程式可能易受攻擊的點之後，您可以判斷每個時間點可能發生的威脅類型。 請考慮下列型態的問題：

• 要保護每個資源的安全性機制有哪些？
• 所有轉換和介面是否都受到適當保護？
• 不當使用功能可能會不小心危害安全性嗎？
• 惡意使用功能會危害安全性嗎？
• 默認設定是否提供適當的安全性？

威脅分類的 STRIDE 方法

縮略字 STRIDE 描述軟體威脅的六種類別。 此縮略字衍生自：

• 偽裝
• Tampering
• 拒絕
• Information 洩漏
• 拒絕服務
• 權限提升

使用 STRIDE 做為指南，您可以針對可能以驅動程式為目標的攻擊類型提出詳細問題。 目標是要判斷在驅動程式中每個易受攻擊點可能的攻擊類型，然後為每個可能的攻擊建立案例。

• 偽裝 是冒用他人的憑證來存取原本無法存取的資產。 進程會藉由傳遞偽造或遭竊的認證來發動冒充攻擊。

• 竄改 是為了發動攻擊而更改數據。 例如，如果必要的驅動程式檔案未受到驅動程式簽署和訪問控制清單 （ACL） 的適當保護，驅動程式可能會容易遭到竄改。 在此情況下，惡意使用者可能會改變檔案，因而破壞系統安全性。

• 否認發生在使用者否認執行某個動作，但動作的目標無法證明事實。 如果驅動程式未記錄可能危害安全性的動作，則可能會受到否認性威脅的影響。 例如，如果視訊裝置的驅動程式沒有記錄變更裝置特性的要求，例如焦點、掃描區域、影像擷取的頻率、所擷取影像的目標位置等等，可能會受到拒絕。 產生的映像可能會損毀，但系統管理員無法判斷哪個使用者造成問題。

• 資訊洩漏 威脅與名稱完全一樣：向沒有許可權查看資訊的使用者洩漏資訊。 任何傳遞資訊給用戶緩衝區或從用戶緩衝區傳遞信息的驅動程式都容易受到資訊洩漏威脅的影響。 若要避免資訊洩漏威脅，驅動程式必須先驗證每個用戶緩衝區的長度，並在寫入數據之前將緩衝區初始化為零。

• 拒絕服務 攻擊威脅有效使用者存取資源的能力。 資源可以是磁碟空間、網路連線或實體裝置。 效能降低到無法接受層級的攻擊也會被視為阻斷服務攻擊。 如果資源耗用量阻礙其他有效使用者執行其工作的能力，則用戶進程不必要地壟斷系統資源的驅動程式可能會容易受到拒絕服務攻擊。

  例如，驅動程式可能會在 IRQL = PASSIVE_LEVEL執行時，使用號誌來保護數據結構。 不過，驅動程式必須取得並釋放 KeEnterCriticalRegion/KeLeaveCriticalRegion 配對內的號誌，這會停用並重新啟用異步過程調用的傳遞（APC）。 如果驅動程式無法使用這些例程，APC 可能會導致作業系統暫停持有信號量的線程。 因此，其他程式（包括系統管理員所建立的程式）將無法取得結構的存取權。

• 如果非特殊許可權的使用者取得特殊許可權狀態，可能會發生 特權提升 攻擊。 將使用者模式句柄傳遞至 ZwXxx 例程的核心模式驅動程式很容易遭受特權提升攻擊，因為 ZwXxx 例程會略過安全性檢查。 核心模式驅動程式必須驗證他們從使用者模式呼叫端接收的每個句柄。

  如果內核模式驅動程式依賴 IRP 標頭中的 RequestorMode 值來判斷 I/O 要求是否來自內核模式或使用者模式呼叫者，也可能會發生特權提升攻擊。 在從網路或伺服器服務 （SRVSVC） 抵達的 IRP 中，不論要求的來源為何， RequestorMode 的值都是 KernelMode。 若要避免這類攻擊，驅動程式必須針對這類要求執行訪問控制檢查，而不只是使用 RequestorMode 的值。

驅動程式分析技術

組織分析的簡單方式是列出易受攻擊的區域，以及每種威脅類型的一或多個案例。

若要執行徹底的分析，您必須探索驅動程式中每個潛在弱點的威脅可能性。 在每個易受攻擊點上，判斷可能的威脅類別（詐騙、竄改、否認、資訊洩漏、阻斷服務及特權提升）。 然後為每個合理的威脅建立一或多個攻擊案例。

例如，請考慮IRP_MJ_DEVICE_CONTROL要求的數據流，如上圖所示。 下表顯示驅動程式在處理這類要求時可能會遇到的兩種威脅類型：

易受攻擊點	潛在威脅 （STRIDE）	情境
IRP_MJ_DEVICE_CONTROL要求	拒絕服務 提高權限	用戶進程會發出一連串導致裝置失敗的 IOCTL。 用戶程式會發出允許FILE_ANY_ACCESS的IOCTL。

一個威脅通常與另一個威脅相關。 例如，利用特權提升威脅的攻擊可能會導致資訊洩漏或阻斷服務。 此外，某些類型的攻擊取決於一系列事件。 惡意使用者可能會從利用特權提升的威脅開始攻擊。 然後，透過具有更高許可權的新增功能，使用者可能會發現並惡意探索其他弱點。

威脅樹狀結構與大綱在模型化這類複雜案例時很有用。

威脅樹狀結構是顯示威脅或弱點階層的圖表;基本上，威脅樹狀結構會模擬惡意使用者掛接攻擊的步驟。 攻擊的最終目標是在樹頂端。 每個次級層級會顯示執行攻擊所需的步驟。 下圖是上述範例中拒絕服務案例的簡單威脅樹狀結構。

威脅樹狀結構會顯示掛接特定攻擊的必要步驟，以及步驟之間的關聯性。 大綱是威脅樹的替代方案。

大綱只會依階層順序列出攻擊特定威脅的步驟。 例如：

1.0 導致裝置停止回應。

1.1 在失敗序列中發出 IOCTLS。

1.1.1 決定導致裝置失敗的順序。

1.1.2 取得提升的權限以發出內部 IOCTL。

任何一種技術都可協助您瞭解哪些威脅最危險，以及設計中哪些弱點最為嚴重。

快速路徑威脅模型化

如果資源有限，而不是建立完整的威脅模型圖表，則可以建立摘要大綱來協助評估驅動程式的安全性風險。 例如，下列文字描述在上一個範例中所提到的範例驅動程序中繪製的一些表面區域。

驅動程式會從作系統接收數種要求類型的數據：

• 要求透過呼叫 DriverEntry、 DriverUnload 和 AddDevice 例程來執行驅動程式及其裝置的系統管理工作
• 隨插即用要求 （IRP_MJ_PNP）
• 電源管理要求（IRP_MJ_POWER）
• 內部裝置 I/O 控制要求 （IRP_MJ_INTERNAL_DEVICE_CONTROL）

為了回應這些要求，數據會從驅動程式流回作系統作為狀態資訊。 驅動程式會在下列類型的要求中接收來自使用者進程的數據：

• 建立、讀取和寫入要求（IRP_MJ_CREATE、IRP_MJ_READ或IRP_MJ_WRITE）
• 公用裝置 I/O 控制要求 （IRP_MJ_DEVICE_ CONTROL）

為了回應這些要求，輸出數據和狀態資訊會從驅動程式傳回用戶進程。

透過對驅動程式的數據流有基本的理解，您可以檢查每個輸入和輸出區域是否存在可能的威脅。

威脅評估的 DREAD 方法

判斷驅動程式可能受到攻擊的方式和位置不夠。 然後，您必須評估這些潛在威脅、判斷其相對優先順序，並設計風險降低策略。

DREAD 是一個縮略字，描述評估軟體威脅的五個準則。 DREAD 代表：

• 損傷
• Reproducibility
• E可利用性
• 受影響的使用者
• D可復原性

若要排定驅動程式的威脅優先順序，請在 DREAD 評估準則的所有 5 個上，將每個威脅排名 1 到 10，然後新增分數並除以 5（準則數目）。 結果是每個威脅的數值分數介於 1 到 10 之間。 高分表示嚴重威脅。

• 損毀。 評估安全性攻擊可能造成的損害顯然是威脅模型化的重要部分。 損毀可能包括數據遺失、硬體或媒體故障、不合格效能，或任何適用於您裝置及其作環境的類似量值。

• 重現性 是衡量指定型別攻擊成功頻率的量值。 容易重現的威脅比那些很少發生或無法預測的漏洞更容易被利用。 例如，那些預設安裝或在每個潛在程式代碼路徑中使用的功能所面臨的威脅，都是高度可重現的。

• 可利用性 會評估發動攻擊所需的努力和專業知識。 對於一名相對缺乏經驗的大學生都能攻擊的威脅來說，這是一個高度可利用的漏洞。 需要高技能人員且執行成本高昂的攻擊較不具利用性。

  在評估可被利用性時，也請考慮潛在攻擊者的數目。 任何遠端匿名使用者都可以利用的威脅，比需要現場高度授權用戶的威脅更容易被利用。

• 受影響的使用者。 受攻擊影響的用戶數目是評估威脅的另一個重要因素。 影響最多一或兩個用戶的攻擊在這項評量中得分相對較低。 相反地，使網路伺服器當機的阻斷服務攻擊可能會影響數千位使用者，因此其重要性評級會更高。

• 可被利用性 是威脅被利用的可能性。 可探索性難以準確估計。 最安全的方法是假設任何弱點最終都會利用，因此，依賴其他措施來建立威脅的相對排名。

範例：使用 DREAD 評估威脅

延續前面討論的範例，下表顯示設計師如何評估假設的拒絕服務攻擊。

DREAD 準則	分數	評論
損傷	8	暫時中斷工作，但不會造成永久損壞或數據遺失。
再現性	10	導致裝置每次都故障。
可利用性	7	需要專注的心力來判斷命令順序。
受影響的使用者	10	影響市場上此裝置的每個型號。
可探索性	10	假設每個潛在威脅都將被發現。
總：	9.0	減輕此問題是高優先順序。

減輕威脅

您的驅動程式設計應該減輕模型公開的所有威脅。 不過，在某些情況下，風險降低可能並不實用。 例如，假設攻擊可能會影響極少數使用者，而且不太可能造成數據或系統可用性遺失。 如果減輕這類威脅需要數個月的額外工作，您可能會合理地選擇花額外的時間測試驅動程式。 不過，請記住，最終惡意使用者可能會發現弱點並掛接攻擊，然後驅動程式將需要修補問題。

在更廣泛的安全性開發生命週期程式中納入威脅模型化

請考慮在更廣泛的安全開發生命週期中包含威脅模型化程式 - SDL。

Microsoft SDL 程式提供一些建議的軟體開發程式，可修改以符合任何組織大小，包括單一開發人員。 請考慮將 SDL 建議的元件新增至軟體開發程式。

如需詳細資訊，請參閱 Microsoft安全性開發週期 （SDL） – 程式指引。

訓練和組織功能 - 追求軟體開發安全性訓練，以擴充您辨識和補救軟體弱點的能力。

Microsoft提供其四個核心 SDL 訓練課程以供下載。 Microsoft安全性開發生命週期核心訓練課程

如需 SDL 訓練的詳細資訊，請參閱這份白皮書。 Microsoft SDL 的基本軟體安全性訓練

需求和設計 - 建置信任軟體的最佳機會是在新版本或新版本的初始規劃階段，因為開發小組可以識別關鍵物件並整合安全性和隱私權，進而將計劃和排程中斷降至最低。

此階段的主要輸出是設定特定的安全性目標。 例如，決定所有程式代碼都應該以零警告通過Visual Studio程式碼分析中的「所有規則」。

實作 - 所有開發小組都應該定義併發佈核准的工具清單及其相關聯的安全性檢查，例如編譯程式/鏈接器選項和警告。

對於驅動程式開發人員來說，大部分有用的工作都是在這個階段完成的。 撰寫程式代碼時，會檢閱是否有可能的弱點。 程式代碼分析和驅動程式驗證器等工具可用來尋找可強化的程式代碼區域。

驗證 - 驗證 是軟體功能完成的點，並且會根據需求和設計階段中所述的安全性目標進行測試。

其他工具，例如 binscope 和模糊測試人員，可用來驗證安全性設計目標是否已符合，且程式代碼已準備好寄送

發行和回應 - 為了準備發行產品，建議您建立事件響應計劃，以描述您將如何回應新的威脅，以及如何在驅動程式出貨后提供服務。 事先執行這項工作將表示，如果在已出貨的程式代碼中識別出安全性問題，您將能夠更快回應。

如需 SDL 程式的詳細資訊，請參閱下列其他資源：

• 這是 Microsoft SDL 的主要網站，並提供 SDL 的概述。 https://www.microsoft.com/sdl

• 此部落格說明如何下載由 Michael Howard 和 Steve Lipner 所著、名為 《安全性開發生命週期：SDL》 的免費電子書。 https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• 此頁面提供其他SDL發行集的連結。 https://www.microsoft.com/SDL/Resources/publications.aspx

行動呼籲

針對驅動程式開發人員：

• 將威脅模型化成為驅動程序設計的一部分。
• 採取步驟，以有效率地降低驅動程式程式代碼中的威脅。
• 熟悉適用於驅動程式和裝置類型的安全性和可靠性問題。 如需詳細資訊，請參閱 Windows 設備驅動器套件 （WDK） 的裝置特定區段。
• 瞭解作業系統、I/O 管理員和任何較高層級的驅動程式會執行哪些檢查，然後使用者的要求才會到達您的驅動程式，以及哪些檢查它們不會執行。
• 使用 WDK 中的工具，例如驅動程式驗證器來測試及驗證驅動程式。
• 檢閱已知威脅和軟體弱點的公用資料庫。

如需其他驅動程式安全性資源，請參閱 驅動程式安全性檢查清單。

軟體安全性資源

書籍

撰寫安全程式代碼，邁克爾·霍華德和大衛·萊布蘭克的第二版

24 軟體安全性的致命罪：程序設計缺陷和如何修正它們，第一版由邁克爾·霍華德、大衛·勒布蘭克和約翰·維加

軟體安全性評估的藝術：識別和防止軟體弱點，由馬克·道德、約翰·麥當勞和賈斯汀·舒赫

Microsoft硬體與驅動程式開發人員資訊

取消 Windows 驅動程式中的邏輯 白皮書

Windows 安全性模型：每個驅動程式寫入器需要知道的內容

Microsoft Windows 驅動程式開發工具套件 （DDK）

請參閱 Kernel-Mode 驅動程式架構中的驅動程式程式設計技術

測試工具

如需效能和相容性測試，請參閱 Windows 硬體實驗室套件

已知威脅和軟體弱點的公用資料庫

若要擴充軟體威脅的知識，請檢閱已知威脅和軟體弱點的可用公用資料庫。

• 常見的弱點和暴露程度（CVE）： https://cve.mitre.org/
• 常見弱點列舉： https://cwe.mitre.org/
• 常見的攻擊模式列舉和分類： https://capec.mitre.org/index.html
• NIST 會維護一個網站，描述如何編錄弱點： https://samate.nist.gov/BF/

另請參閱

驅動程式安全性檢查清單