驱动程序的威胁建模

驱动程序编写者和架构师在任何驱动程序的设计过程中都应当进行威胁建模。 本主题提供有关为 Windows 驱动程序创建威胁模型的指南。

安全性应该是任何驱动程序的基本设计点。 任何成功的产品都是目标。 如果你正在编写适用于 Windows 的驱动程序，则必须假设某个时候有人会尝试使用你的驱动程序来危害系统安全性。

设计安全驱动程序涉及：

• 确定驱动程序可能容易受到攻击的点。
• 分析可在每个此类点装载的攻击类型。
• 确保驱动程序的设计方式是阻止此类攻击。

威胁建模是处理这些重要设计任务的结构化方法。 威胁模型是一种对资产的威胁进行分类和分析的方法。 从驱动程序编写者的角度来看，资产是计算机或网络上的硬件、软件和数据。

威胁模型回答以下问题：

• 哪些资产需要保护？
• 资产容易受到哪些威胁？
• 每种威胁的重要性或可能有多大？
• 如何缓解威胁？

威胁建模是软件设计的重要组成部分，因为它可确保安全性内置于产品中，而不是事后处理。 良好的威胁模型有助于在设计过程中查找和防止 bug，从而消除以后可能成本高昂的修补程序，并消除对组织的信誉造成的潜在损害。

本部分将威胁建模的原则应用于驱动程序设计，并提供驱动程序可能容易受到的威胁的示例。 有关软件设计威胁建模的更完整说明，请参阅这些资源。

• Microsoft SDL 网站：

  https://www.microsoft.com/sdl

• Microsoft SDL 的简化实现：

  下载白皮书

• 此博客文章介绍如何下载由 Michael Howard 和 Steve Lipner 撰写的 “安全开发生命周期：SDL”免费副本：

  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 请求定向到类驱动程序，然后类驱动程序调用微型驱动程序中的例程来执行特定任务。 微型驱动程序通常不会接收整个 I/O 请求数据包作为输入;相反，每个回调例程只接收其特定任务所需的数据。

创建数据流关系图时，请记住驱动程序请求的各种源。 在用户计算机上运行的任何代码都可以生成对驱动程序的 I/O 请求，从 Microsoft Office 等已知应用程序到可能可疑来源的免费软件、共享软件和 Web 下载。 根据你的特定设备，你可能还需要考虑公司为支持其设备而附带的媒体编解码器或第三方筛选器。 可能的数据源包括：

• IRP_MJ_XXX驱动程序处理的请求
• 驱动程序定义或处理的 IOCTL
• 驱动程序调用的 API
• 回调例程
• 驱动程序公开的任何其他接口
• 驱动程序读取或写入的文件，包括安装期间使用的文件
• 驱动程序读取或写入的注册表项
• 配置属性页，以及驱动程序使用的用户提供的任何其他信息

模型还应涵盖驱动程序安装和更新过程。 包括驱动程序安装过程中读取或写入的所有文件、目录和注册表项。 另请考虑设备安装程序、共同安装程序和属性页中公开的接口。

驱动程序与外部实体交换数据的任何点都可能容易受到攻击。

分析潜在威胁

确定驱动程序可能易受攻击的点后，可以确定每个点可能发生哪些类型的威胁。 请考虑以下类型的问题：

• 有哪些安全机制来保护每个资源？
• 所有转换和接口是否正确保护？
• 不当使用功能会无意中损害安全性吗？
• 恶意使用功能会危及安全性吗？
• 默认设置是否提供足够的安全性？

威胁分类的 STRIDE 方法

首字母缩略词 STRIDE 描述了对软件的六类威胁。 此首字母缩略词派生自：

• S欺骗
• T安培
• Repudiation
• Information 披露
• 服务的 Denial
• E特权税

使用 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 代表：

• Damage
• Reproducibility
• Exploitability
• ffected 用户
• Discoverability

若要确定对驱动程序的威胁的优先级，请在所有 5 个 DREAD 评估条件中将每个威胁从 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 中的工具（例如驱动程序验证程序）测试和验证驱动程序。
• 查看已知威胁和软件漏洞的公共数据库。

有关其他驱动程序安全资源，请参阅 驱动程序安全清单。

软件安全资源

书籍

编写安全代码，第二版由 Michael Howard 和 David LeBlanc

24 软件安全的致命罪：编程缺陷和如何修复它们，第一版由迈克尔·霍华德、大卫·勒布兰克和约翰·维加

软件安全评估的艺术：识别和预防软件漏洞，作者：Mark Dowd、John McDonald 和 Justin Schuh

Microsoft 硬件和驱动程序开发人员信息

取消 Windows 驱动程序中的逻辑 白皮书

Windows 安全模型：每个驱动程序编写者需要了解的内容

Microsoft Windows 驱动程序开发工具包 (DDK)

请参阅内核模式驱动程序体系结构中的驱动程序编程技术

测试工具

有关性能和兼容性，请参阅测试中的 Windows 硬件实验室工具包

已知威胁和软件漏洞的公共数据库

若要扩展对软件威胁的了解，请查看已知威胁和软件漏洞的可用公共数据库。

• CVE) (常见漏洞和风险： https://cve.mitre.org/
• 常见弱点枚举： https://cwe.mitre.org/
• 常见攻击模式枚举和分类： https://capec.mitre.org/index.html
• NIST 维护一个站点，用于描述如何对漏洞进行编目： https://samate.nist.gov/BF/

另请参阅

驱动程序安全清单