GPU 虚拟地址投毒

摘要 NVIDIA GPUDirect RDMA 和 CUDA 统一内存允许 GPU 直接访问另一块 GPU 的显存，其底层依赖 IOMMU 将虚拟地址映射到物理页。然而，在统一内存页面迁移期间，旧物理页的 IOMMU 映射可能未被及时刷新，导致 GPU A 在释放本地缓存后仍可通过 GPU B 访问到已被重分配的系统内存。攻击者可利用这一“虚拟地址投毒”缺陷，在容器化的多租户 GPU 集群中实施跨 GPU 数据窃取——读取其他容器的模型参数或推理数据，彻底打破 GPU 内存隔离。 CUDA Unified Memory 与 IOMMU 的协同 统一内存的虚拟地址抽象 CUDA 统一内存提供了一个单一的虚拟地址空间，CPU 和所有 GPU 均可访问。 当应用程序调用 cudaMallocManaged 分配统一内存时，CUDA 驱动在内部创建虚拟地址映射，但物理页最初可能仅在 CPU 端分配。当 GPU 第一次访问该地址时，触发缺页，驱动将页面迁移到 GPU 本地显存。后续若另一个 GPU 访问同一地址，页面可从第一个 GPU 的显存通过 NVLink 或 PCIe 直接迁移。…

DNSSEC 密钥标签碰撞

摘要 DNSSEC 通过数字签名保证 DNS 数据的完整性，其信任锚点由 DNSKEY 记录的密钥标签标识。解析器在验证签名时，根据授权签名者（Signer）字段中的密钥标签查找对应的 DNSKEY。然而，16 位的密钥标签空间仅有 65536 种可能，攻击者可以暴力生成一个与信任锚标签相同的恶意密钥，并将其植入精心构造的子域 NSEC3 记录中。部分递归解析器（如 Unbound）在解析路径上的密钥选择逻辑存在缺陷：当响应中包含与当前信任锚标签匹配的非权威 DNSKEY 时，可能错误地将其用于验证签名，导致攻击者伪造的签名被接受，整个 DNSSEC 验证降级为“无保护”状态。 DNSSEC 密钥标签与解析器信任模型 密钥标签的计算方法 DNSSEC 使用 DNSKEY 记录存储区的公钥，每个密钥由 16 位的密钥标签唯一标识（在 RRSIG 和 DS 记录中引用）。密钥标签的计算过程如下（RFC 4034 附录 B）：将 DNSKEY 的 RDATA（标志位、协议、算法、公钥）按网络字节序拼接，然后逐 16 位累加，最后取低 16 位作为标签。算法简单，无密码学强度，仅作为快速索引。 由于算法可逆性弱，攻击者无法直接计算出与特定标签匹配的公钥，但可以反复生成密钥对，计算标签，直到碰出目标标签。对于 16 位空间，平均需要约 32768 次尝试，现代 CPU 在毫秒级内即可完成。因此，密钥标签的碰撞是现实可行的。 解析器的密钥选择路径 以 Unbound 为例，验证签名时的密钥选择流程： 解析器收到包含 RRSIG 的响应，提取 Signer 字段，其中含有密钥标签。…

GSMA SGP.22 的 OTA 下载会话劫持

摘要 eSIM 通过 GSMA SGP.22 规范定义的 RSP 平台实现远程配置文件下载，其安全性依赖于 SM-DP+ 服务器与 eUICC 之间的端到端 TLS 通道以及一次性会话令牌。然而，该协议在会话令牌绑定、推送通知验证和用户确认三个环节存在结构性缺陷：部分运营商实现的 AC Token 未绑定目标设备的 EID，推送通知中的路径信息可被明文嗅探，且 SM-DS 的地址解析缺乏强制证书验证。攻击者可利用这些缺陷，劫持合法用户的配置文件下载会话，在攻击者控制的设备上复制目标配置文件，从而实施 SIM 交换欺诈——无需接触受害者设备或发起社会工程攻击。 eSIM RSP 平台 eSIM 生态的关键角色 GSMA SGP.22 定义的 RSP 消费者解决方案包含四个核心实体： eUICC：嵌入式通用集成电路卡，即 eSIM 芯片，可存储多个运营商配置文件。 LPA：本地配置文件助手，运行在终端设备上，负责与 SM-DP+ 通信、下载和安装配置文件。 SM-DP+：订阅管理数据准备+，运营商侧服务器，负责生成、加密和下发配置文件。 SM-DS：订阅管理发现服务器，可选的中间代理，帮助设备发现待下载的配置文件。 一次完整的 OTA 下载流程如下：运营商准备好配置文件，向用户发送 AC Token 或推送通知。设备上的 LPA 通过 AC Token 或扫描 QR 码获取 SM-DP+ 地址和匹配…

Matter 智能家居的分布式信任崩溃

摘要 Matter 协议通过 Thread 网络实现低功耗智能家居设备的互联，其中 TREL（Thread Radio Encapsulation Link）作为桥接技术，将 Thread 的 IEEE 802.15.4 帧封装为 UDP 包在 Wi-Fi 骨干网上传输。然而，TREL 未强制端到端加密，仅依赖 PAN ID 进行网络隔离，这为跨媒介的信任边界崩溃埋下了伏笔。攻击者可在 Wi-Fi 段部署伪 TREL 端点，拦截并注入“Update Key”广播消息，使全网络设备切换到攻击者已知的密钥，从而静默接管智能门锁、安防传感器等关键设备。 Thread 与 TREL Matter 的分层架构与 Thread 的角色 Matter 是由 CSA（连接标准联盟）推出的统一智能家居应用层协议，工作在 IP 之上。 它依赖底层的网络传输协议，包括 Wi-Fi、Ethernet 以及 Thread。Thread 是一种基于 IEEE 802.15.4 的 IPv6 网状网络协议，专为低功耗、低带宽的 IoT 设备设计，支持自愈网状拓扑与休眠节点。在 Matter 架构中，Thread 通常负责连接门磁、运动传感器、智能门锁等电池供电设备，而 Wi-Fi 承载高带宽设备（如摄像头、语音助手）。…

SPI NOR 内存幽灵

摘要 SPI NOR Flash 作为嵌入式设备、物联网终端及安全芯片的关键非易失性存储介质，存储着固件、引导代码、密钥与证书等敏感信息。然而，其物理擦除机制与文件系统的逻辑删除之间存在根本性的鸿沟：逻辑删除仅清除索引，而实际数据仍残留在存储单元中，直到被显式擦除或覆写。更严峻的是，即使执行了整片擦除，攻击者仍可通过物理读出未分配块、提取磨损均衡映射表或利用电压毛刺使擦除命令提前终止，恢复出厂密钥与证书，甚至还原已删除的固件映像。 SPI NOR NOR Flash 的存储结构 SPI NOR Flash 内部存储阵列由扇区（Sector，通常 4KB）、块（Block，32KB/64KB）或整个芯片组成。NOR 支持随机读取，但写入前必须将目标区域擦除为全 0xFF。擦除操作以扇区或块为单位，通过特定的命令序列（如 Write Enable + Sector Erase）触发，由内部状态机执行，耗时数百毫秒至秒级。 擦除操作本质上是将浮栅上的电子移出，使存储单元回到初始状态。但擦除并非瞬时完成：在状态机执行期间，如果电源不稳定或收到非法命令，擦除可能被中断，导致部分区域未被完全擦除，原有数据仍有残留。 安全擦除的误区 许多安全应用信赖整片擦除（Bulk Erase）命令可以彻底清除所有数据。但实际上，Bulk Erase 的执行时间较长（典型值为数十秒），期间芯片可通过外部引脚（如 RESET# 或 CS#）被中断。 Command (C7h/60h) | v +—-+ CS# _____| |___________________________________________________/_______ <–>(1) <–>(3) t_CSS t_CSH +–+ +–+ +–+ +–+ +–+ SCK __| |__| |__| |__| |_. . .__|…

D-Bus 语义投毒

摘要 D-Bus 是 Linux 桌面环境的神经中枢，Flatpak 和 Snap 等沙箱方案依赖 D-Bus 代理过滤不受信任的调用。然而，xdg-dbus-proxy 的过滤规则存在一个语义漏洞：它根据消息头中的发送者唯一名称来放行回复，却没有验证该名称是否由可信的进程生成。攻击者可以从沙箱内部伪造一条回复消息，冒充系统守护进程（如 org.freedesktop.systemd1），绕过接口白名单，直接调用 systemd 的管理方法创建恶意服务单元，从而逃逸沙箱并以宿主机权限执行任意代码。 D-Bus 安全模型与过滤代理 D-Bus 消息结构与身份标识 D-Bus 通信基于消息总线，最常用的会话总线和系统总线分别处理用户会话和系统级服务。 每条消息包含固定的头部字段：消息类型（方法调用、方法返回、错误、信号）、路径、接口、成员以及若干可选字段，其中 SENDER 字段表示消息的发送者唯一名称（如 :1.42）。总线守护进程 dbus-daemon 在连接建立时为每个连接分配唯一的名称，并在后续消息中自动添加 SENDER 字段——如果消息本身没有提供，daemon 会设置它；但如果消息已经包含了 SENDER，daemon 的行为在不同版本中存在差异：旧版本 daemon 可能直接信任消息中已有的 SENDER 值，而非强制覆盖。 这构成了第一道裂缝：若攻击者能够直接与对端套接字通信并伪造 SENDER，总线守护进程不会拒绝，接收端将信任伪造的发送者身份。 Flatpak 沙箱 Flatpak 等沙箱技术通过 Bubblewrap 限制应用的文件系统和网络访问，并通过 D-Bus 代理 (xdg-dbus-proxy) 控制应用与 D-Bus 总线的交互。代理运行在沙箱外部，根据预定义或动态协商的过滤器规则，对来自沙箱内部的消息进行审查。规则通常基于： 接口和方法名：例如只允许 org.freedesktop.portal.* 接口的调用。 发送者：允许来自特定 D-Bus 名称的回复。 访问方向：允许接收某些信号，禁止发送某些调用。 当沙箱内的应用发送一条方法调用消息时，代理检查目标接口和方法是否在白名单中。对于信号的订阅，代理也进行过滤。但关键的安全漏洞在于：代理在处理回复（类型为 method_return 或 error）时，会检查该回复是否对应于之前从沙箱发出的某个调用。为了将此回复路由给正确的调用者，代理会查看回复消息中的 reply_serial 字段（匹配之前调用的序列号）。然而，代理假设只有合法的服务进程才会生成带有正确 reply_serial 和 SENDER 的回复——它并未验证该回复消息是否真的来自目标服务，也未强制要求回复消息中的 SENDER 必须与之前调用的 DESTINATION 匹配。 过滤机制的语义漏洞 攻击场景：沙箱内的恶意应用希望调用系统总线上的 org.freedesktop.systemd1.Manager.StartTransientUnit 方法来创建一个恶意服务单元，该方法在沙箱的过滤器白名单中显然不存在。但攻击者可以采用以下步骤绕过： 沙箱应用向系统总线发送一条伪造的方法调用，声称目的地是 org.freedesktop.systemd1，但实际上这条调用并不真正发送到 systemd，而是由攻击者自己在沙箱内部的另一个线程接收并处理。 攻击者构造一条伪造的回复消息，类型为 method_return，reply_serial 匹配之前那条调用的序列号，SENDER 字段设置为 :1.XXX（实际 systemd 拥有的唯一名称），但这条回复实际上是由沙箱内部的恶意线程生成并通过沙箱与代理之间的套接字发送给代理的。 代理收到这条“回复”后，根据 reply_serial 找到之前尚未完成的调用记录，认为这确实是 systemd 对该调用的回复，于是将其放行——因为代理默认放行已许可调用的回复。 攻击者在构造这条“回复”消息的同时，在消息体中嵌入了另一个新的方法调用：在 method_return 的回复体内部，可以放置一条任意的方法调用（这是…