摘要 Linux 内核的 XFRM 框架负责 IPsec 变换，其中 ESP 的 BEET（Bound End-to-End Tunnel）模式在解密 IPsec 包后，会重构内部 IP 头。然而，在某些内核路径中，用于构造新 IP 头的 skb 区域未被完全初始化为零，导致内核堆中残留的指针或数据碎片被嵌入数据包并返回给远端用户。攻击者可从互联网发送特制的空载荷 ESP 包，在解密后的响应中泄露堆上的内核基址、堆地址甚至密钥材料，从而彻底击溃 KASLR 并为后续内核利用铺路。 BEET 模式 IPsec ESP 隧道 IPsec ESP 支持两种经典模式：传输模式仅加密传输层以上内容，保留原始 IP 头；隧道模式则加密整个原始 IP 数据包，并添加新的外部 IP 头。BEET 模式是两者的混合：它使用外部 IP 头进行路由，但内部 IP 头在解密后被重新计算，并以最小开销嵌入外部 IP 头之后。这种模式常用于移动 IPv6 和端到端加密场景。 其核心特性对比可以参考以下表： 维度 传输模式 隧道模式 BEET 模式 IP 标头数量 1 个（原始…
摘要 Swift 5.10 引入了严格并发检查，通过 @Sendable 闭包和 Actor 隔离在编译期防止数据竞争。然而，这些安全保证几乎完全依赖于编译器的静态分析，运行时缺乏强制机制。攻击者可利用 UnsafeMutablePointer 将非 Sendable 类型强制转换为 @Sendable 闭包，并将其跨 Actor 传递；在另一个 Actor 上通过 withUnsafeCurrentTask 执行任意代码，破坏原 Actor 的状态，实现数据竞争和类型混淆。更隐蔽的是，利用 TaskLocal 传递裸指针，或通过 GCD 直接调度绕过 @MainActor 隔离，可在服务器端 Swift 应用（如 Vapor）中实现持久化的隐蔽后门。 Sendable与 Actor 隔离 Sendable协议的类型安全承诺 Sendable 是 Swift 并发模型的核心协议之一，用于标记可以安全地跨并发域传递的类型。值类型（如 Int、String）、无内部共享状态的 final class 以及显式标记为 @Sendable 的闭包均符合 Sendable。编译器会检查所有跨 Actor 或 Task 传递的值的类型，如果非 Sendable 类型被错误传递，则发出严格并发检查的编译错误或警告。 在底层，@Sendable 闭包会被编译器转换为捕获不可变副本或同步原语保护的上下文，但这一转换完全发生在 SIL（Swift Intermediate Language）层，最终生成的 LLVM IR 中并没有额外的运行时检查。也就是说，一旦绕过编译器的静态检查，运行时将不加区别地执行任何闭包。 Actor 隔离的执行语义 Actor 是一种引用类型，通过串行执行队列保护其内部状态。所有对 Actor 可变状态的访问都必须通过 await 异步调用或在 Actor 内部的同步代码中进行。编译器负责保证这一约束：在 Actor 外部，无法直接访问其存储属性或调用未标记 nonisolated 的方法。 运行时实现上，Actor 携带一个内部的 DistributedActor 标识和串行执行器。当任务需要在 Actor 上执行时，会被调度到该执行器上排队。但 Actor 的执行器本身是可替换的，且 GCD 等旧并发 API 可以绕过这一调度机制，直接将任务提交到任意队列执行。这构成了 Actor…
摘要 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 通过数字签名保证 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 字段，其中含有密钥标签。…
摘要 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 协议通过 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 承载高带宽设备（如摄像头、语音助手）。…