1. VxWorks安全威胁建模
VxWorks作为广泛应用于航空、航天、工业控制、医疗设备和网络设备的实时操作系统，其安全问题的特殊性在于：它通常运行在资源受限的嵌入式环境中，长期无人值守，且一旦被攻破，后果往往直接作用于物理世界。因此，对VxWorks进行安全加固的第一步，不是急于修改配置或打补丁，而是建立一套系统的威胁模型——明确“谁可能攻击、从哪里攻击、攻击什么、会造成什么后果”。
一、攻击面分析：从启动到通信的完整暴露路径
攻击面是指系统中所有可被外部访问、可被利用的入口点集合。对VxWorks而言，攻击面并非只存在于网络协议栈，而是贯穿启动、运行、调试、通信和升级全过程。可以按以下层次梳理：
- 启动与引导层：BootROM、U-Boot或VxWorks引导参数、启动脚本。若引导介质未做完整性校验，攻击者可替换镜像或篡改启动参数，实现持久化植入。
- 内核与系统服务层：任务调度、内存管理、中断处理、系统调用接口。VxWorks内核通常以单一地址空间运行，一旦某个任务被劫持，可能直接影响整个系统。
- 网络协议栈：TCP/IP栈、UDP、ARP、ICMP、DNS、DHCP等。这是VxWorks最常被攻击的入口，URGENT/11和TCP/IP栈漏洞均属此类。
- 设备接口与驱动层：串口、USB、CAN、以太网、Wi-Fi、蓝牙等。物理接口往往被忽视，但调试串口若未关闭，可直接获得Shell。
- 调试与维护接口：WindSh、目标服务器（target server）、TFTP、FTP、Telnet、Rlogin、调试代理。这些接口在开发阶段极为方便，但在产品中若未关闭，等同于“后门”。
- 应用与中间件层：Web服务器、SNMP、OPC UA、MQTT、自定义协议服务。应用层漏洞可直接导致业务中断或数据泄露。
攻击面分析的核心不是罗列接口，而是判断每个入口的“可达性”和“可利用性”。例如，一个仅在内网开放的Telnet服务，其风险低于一个暴露在公网且使用默认口令的调试端口。实际工程中，建议为每个入口标注：访问路径、认证方式、默认状态、已知漏洞、影响等级。
二、威胁来源分类：谁在攻击，动机是什么
威胁来源决定了攻击者的能力、资源和攻击路径。在VxWorks场景中，主要分为四类：
远程网络攻击者是最常见的一类。他们通过网络可达的端口和服务发起攻击，典型目标是TCP/IP协议栈。URGENT/11（CVE-2019-12256等）就是利用IPnet协议栈中IPv4选项解析缺陷，攻击者发送特制数据包即可触发远程代码执行。这类攻击者通常具备较强的漏洞挖掘能力，但受限于网络隔离，可能无法直接接触设备。
本地物理接触者包括维护人员、现场工程师或恶意内部人员。他们可以通过串口、USB或调试接口直接访问设备。如果产品出厂时未关闭WindSh或目标服务器，攻击者连接串口后即可获得Shell，执行任意命令。这类威胁的隐蔽性在于：它不需要网络可达，但需要物理接近。
供应链与内部威胁涉及第三方组件、BSP驱动、外包代码或内部人员。VxWorks生态中大量使用第三方中间件和驱动，若未经过安全审计，可能引入后门或漏洞。内部人员则可能因误操作或越权访问导致配置泄露。
环境与自然威胁虽非恶意，但同样影响安全。例如，电磁干扰导致通信异常、电源波动引发系统复位、存储介质老化造成固件损坏。在威胁建模中，这类因素应作为“可用性”维度的输入。
三、STRIDE建模方法在VxWorks中的落地
STRIDE是微软提出的威胁分类框架，包含六类：Spoofing（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）。在VxWorks中，每一类都有具体的表现形式：
| STRIDE类别 | VxWorks典型场景 | 示例 |
|---|---|---|
| Spoofing | 伪造ARP响应、伪造DHCP服务器 | 攻击者冒充网关，劫持设备通信 |
| Tampering | 篡改启动镜像、修改配置文件 | 替换BootROM中的VxWorks镜像 |
| Repudiation | 缺乏日志审计，无法追溯操作 | 调试口执行命令后无记录 |
| Information Disclosure | 调试信息泄露、内存未初始化 | WindSh打印内核地址和任务列表 |
| Denial of Service | TCP/IP栈资源耗尽、任务阻塞 | URGENT/11导致IPnet崩溃 |
| Elevation of Privilege | 从用户任务提升到内核权限 | 利用驱动漏洞执行内核代码 |
实际建模时，建议按“数据流图+STRIDE”的方式操作：先画出系统的数据流图，标注外部实体、处理过程、数据存储和数据流；然后对每个元素逐一应用STRIDE六问。例如，对于“网络协议栈”这个处理过程，问：能否仿冒数据包来源？能否篡改包内容？能否否认发送过？能否泄露包内信息？能否耗尽栈资源？能否利用栈漏洞提权？
四、典型漏洞案例：URGENT/11与TCP/IP栈
URGENT/11是2019年披露的VxWorks IPnet协议栈系列漏洞，共11个CVE，影响数百万台设备。其中CVE-2019-12256最为严重：攻击者发送带有畸形IPv4选项的数据包，可导致栈溢出并远程执行代码。该漏洞的根源在于IPnet对IPv4选项长度字段未做充分校验，攻击者可以构造超长选项，覆盖相邻内存区域。
另一个典型案例是CVE-2019-12255，涉及TCP的URG标志处理。攻击者发送带有URG标志的TCP包，可触发整数下溢，导致内存破坏。这两个案例说明：VxWorks的TCP/IP栈虽然经过长期验证，但在面对畸形包和边界条件时仍存在风险。安全需求定义时，必须明确：协议栈是否支持关闭不必要的选项？是否启用包过滤？是否对入站包做长度和格式校验？
五、安全需求定义：从威胁模型到可验证指标
威胁建模的最终产出是安全需求。安全需求必须可验证、可测试，而不是“提高安全性”这类空泛表述。以下是一组针对VxWorks的示例安全需求，可作为需求定义的参考：
- 启动完整性：设备启动时，BootROM必须对VxWorks镜像进行数字签名校验，校验失败则拒绝启动并记录事件。
- 调试接口管控：产品发布版本中，WindSh、目标服务器、Telnet、FTP必须默认关闭；若必须开启，需通过物理跳线或加密认证后才能启用。
- 网络协议栈加固：禁用IP转发、源路由、ICMP重定向；对入站TCP/UDP包做长度和选项校验；限制半开连接数。
- 最小权限：应用任务不得直接访问内核地址空间；驱动加载需签名验证。
- 审计与日志：所有认证失败、配置变更、调试接口访问必须记录到非易失存储，日志需防篡改。
这些需求可以直接转化为测试用例。例如，针对“调试接口管控”，测试方法是：使用串口连接设备，尝试进入WindSh，预期结果为拒绝访问或需要口令；针对“启动完整性”，测试方法是：篡改镜像后重启，预期结果为启动失败并记录事件。
总结来说，VxWorks安全威胁建模的核心逻辑是：先看清攻击面，再识别威胁来源，然后用STRIDE系统化分类，最后将威胁转化为可验证的安全需求。URGENT/11等案例提醒我们，即使是成熟的实时操作系统，其协议栈和调试接口也可能成为攻击者的突破口。只有把威胁模型做扎实，后续的加固措施才有明确的靶心。