USB-C 模拟攻击

摘要 USB Power Delivery 3.1 通过 Configuration Channel 引脚协商高达 240W 的电力与 Alternate Mode 数据，但其协议栈在处理供应商自定义消息（VDM）时缺乏严格的长度验证。攻击者可利用 FPGA 或 STM32 微控制器模拟 PD PHY，发送畸形的 VDM 数据包，触发接收端解析器的堆溢出，进而在 USB4 主控或电源管理芯片的固件中执行任意代码。同时，通过伪造 e-Marker 电缆身份，攻击者能让主机误信其连接了高规格线缆，从而开放超过物理承载能力的电流，引发物理烧毁；或伪装成 DisplayPort Alt Mode 设备，在无用户授权的情况下建立视频输出通道，实现隐蔽监控。 PD协议栈 CC 引脚的半双工通信与 BMC 编码 USB-C 接口的 Configuration Channel（CC）引脚是 PD 协议通信的物理介质。与 USB 数据线不同，CC 采用单线半双工模式，使用双相标记编码（BMC）以 300 kbps 速率传输数据。消息以 64 比特的前导码开头，后接 SOP（Start of Packet）定界符，再跟 16 比特的消息头和可变长度的有效载荷，最后是 32…

AI 模型「溶枪」

摘要 开放神经网络交换格式（ONNX）通过 Protobuf 结构描述计算图，其灵活的自定义操作机制允许绑定任意外部动态库。这一设计便利了硬件厂商的算子优化，却也使得模型文件成为可注入恶意代码的“特洛伊木马”。攻击者可将后门逻辑伪装成合法的预处理或量化算子，在模型中嵌入定制的动态库加载指令。当模型被 ONNX Runtime 等服务加载时，隐藏的代码便会悄无声息地启动反向 Shell、窃取推理数据或篡改预测结果。由于计算图结构极其复杂，大多数静态扫描工具难以识别这类寄生在算子语义中的“溶枪式”后门。 ONNX 的自定义算子和外部数据信任链路 自定义算子的能力边界 ONNX 的自定义算子通过 op_type 和 domain 标识，由推理引擎注册的内核实现。ONNX Runtime 提供 RegisterCustomOp 接口，允许开发者动态添加算子，内核可以调用任意系统 API。这一能力原本是为硬件加速器（如 TPU）预留的，却也为攻击者打开了执行任意代码的通道。攻击者只需将恶意内核封装为动态库（libCustomOp.so），并在模型加载时通过配置文件或环境变量指定该库的路径，即可在推理进程上下文中执行任意操作。 更隐蔽的方式是，攻击者直接修改模型文件中的 external_data 字段，将恶意动态库打包为张量的“权重数据”。在 ONNX 规范中，大张量可通过 external_data 引用外部文件，但也可以将整个库嵌入模型内部。当模型首次推理时，自定义内核的初始化函数会解包该文件到临时目录并调用 dlopen，从而完成自我加载——整个过程无需用户额外配置任何库文件。 模型加载流程中的可注入点 ONNX Runtime 的模型加载流程主要包括：解析模型文件 → 构建计算图 → 注册内置和自定义算子 → 分配内存 → 执行图。 攻击者可劫持以下环节： 图构建阶段：通过修改 GraphProto 中的 node 条目，插入一个高优先级的自定义算子，声称用于“权重解密”或“校验和验证”。该算子会在模型加载后立即执行，先于正常推理。 算子注册阶段：若推理服务允许通过环境变量 ORT_CUSTOM_OP_LIBRARY 指定自定义库，攻击者可通过模型附带的启动脚本设置该变量，实现环境投毒。 外部数据解析阶段：利用 external_data 的 offset 和 length 字段，将一个看似正常的张量指向模型文件末尾的恶意 Shellcode，再由自定义算子读取并执行。 多阶段溶枪攻击链 环境准备与侦察 攻击者植入的第一个自定义算子名为 EnvProbe，域为 ai.utils。它在 ONNX 图中被标记为 Constant 节点的“消费者”，宣称负责“设备能力探测”。实际上，该算子执行以下操作： 检查当前进程权限和操作系统版本； 读取环境变量，确认是否在目标推理服务器上运行； 若判定为生产环境，则释放第二阶段载荷；否则保持静默。 这种选择性激活的策略有效规避了在开发或测试环境中被提前发现的风险。 动态库落地与持久化 EnvProbe 通过 external_data 获取一个压缩的共享库 libsyslog.so（伪装成日志库）。算子将其解压到 ~/.cache/ort_custom/libsyslog.so，并调用 dlopen 加载。该库的构造函数会： 修改 ~/.bashrc，追加一条自动拉取远程脚本的命令； 在 /etc/cron.d/ort_health 中写入一个每 10 分钟执行的定时任务，用于维持反向 Shell； 注册一个新的自定义算子 DataSink，用于后续数据窃取。 数据窃取与回传…

TrustZone 硅后门

摘要 ARM TrustZone 将系统划分为普通世界与安全世界，通过安全监控调用（SMC）实现切换。高通、联发科等厂商在实现 SMC 处理表时，常未严格验证调用 ID 范围，且允许在 EL2/EL1 特权下修改 SMC 表指针。攻击者可利用这些漏洞，劫持合法 SMC 调用，将其重定向至恶意处理函数，从普通世界读取安全世界内存（包括指纹模板、加密密钥），甚至将恶意载荷注入安全用户态（S-EL0）的可信应用（TA）中，实现持久化隐蔽后门。 SMC 指令与调用表 SMC 快速调用 在 TrustZone 架构中，普通世界（Normal World）的代码无论特权级多高，都无法直接访问标记为安全世界的物理内存或外设。唯一受控的跨域交互是通过 SMC（Secure Monitor Call） 指令。当普通世界执行 SMC #imm 时，CPU 陷入安全监控模式（Monitor Mode）或直接切换到安全世界的 EL3 固件。SMC 指令携带一个 16 位立即数，作为调用 ID，安全监控软件根据该 ID 查找预定义的函数表，执行相应的安全服务。 安全监控软件通常由 OEM 提供（如 Qualcomm 的 QSEE、MTK 的 Kinibi），运行在 EL3，充当 TrustZone 的看门人。其内部维护一个 SMC 调度表，每个条目包含一个调用 ID、处理函数指针以及参数个数等信息。 调用表的静态与动态注册 OEM 的 SMC 表通常分为两部分：编译期静态表（如高通 qsee_handle_smc）和动态注册表（用于后续加载的安全世界内核模块）。动态表的基址常存储在 EL3 固件的数据段中，可通过逆向固件或利用内存泄露漏洞获取。在某些实现中，动态表的尾指针未正确校验，导致调用 ID…

剪贴板即信道

摘要 异步剪贴板 API 为 Web 应用提供了读、写系统剪贴板的能力，但 navigator.clipboard.write() 的异步执行与用户 paste 事件的同步触发之间，存在一个容易被忽略的原子性缺陷。攻击者可利用同一用户手势先后调用 write() 和 read()，通过 Promise.race 构造竞态条件，在浏览器实际写入新内容之前读取到剪贴板中尚未被覆盖的残留数据——而这些数据可能来自另一个域，包含密码管理器自动填充的凭据、2FA 种子或私钥。更危险的是，结合密码管理器的“复制密码”功能和 WebAuthn 条件 UI 的自动填充行为，窃取甚至不需要用户额外的粘贴操作。 异步剪贴板 API 的安全模型 从 execCommand 到 navigator.clipboard 在 navigator.clipboard 出现之前，页面只能通过 document.execCommand(‘copy’) 和 document.execCommand(‘paste’) 操作剪贴板，且后者仅在浏览器扩展或用户主动粘贴时可用。异步剪贴板 API 允许页面使用 readText() 和 writeText() 直接读取和写入文本，前提是获得用户许可（对于 read，通常要求页面可见且由用户手势触发）并且传输数据遵循安全上下文（HTTPS）。 关键设计：write() 返回一个 Promise，在数据被系统剪贴板确认后解析；read() 同样返回一个 Promise，在读取到当前剪贴板内容时解析。二者都是在“任务队列”中异步执行的，但在一次用户手势（如 click 事件）中，可以同时调用两个方法而不相互阻塞。 同一个点击下的 write 与 read 考虑以下代码： button.addEventListener('click', async () => { navigator.clipboard.writeText('A'.repeat(100)); const data = await navigator.clipboard.readText(); console.log(data); }); 开发者预期 readText() 会返回刚才写入的 ‘AAA…’，但实际结果取决于 UA 的事件循环调度：如果 writeText() 的内部实现是“先调度写入任务，再解析 Promise”，而 readText() 在写入任务实际执行之前就已经从系统剪贴板读取了内容，那么 data 将是调用 writeText()之前 剪贴板中的旧数据。这个顺序差异构成了可被利用的竞态窗口。 竞态条件的微观时序 任务队列的调度间隙 浏览器主线程执行模型： 用户点击，click 事件处理开始。 调用 writeText()，UA 创建一个“写剪贴板”任务并将其排入任务队列，同时返回一个 Promise。 继续执行，调用 readText()，UA 创建一个“读剪贴板”任务排入队列，返回…

虚悬页表

摘要 内核页表隔离 (KPTI) 是防御 Meltdown 类攻击的关键机制，通过分离用户态与内核态页表，确保用户态代码无法直接窥探内核地址空间。在 ARM64 上，KPTI 由 CONFIG_UNMAP_KERNEL_AT_EL0 和 kpti 引导参数控制，利用 TTBR0_EL1 与 TTBR1_EL1 的切换将内核映射仅在异常入口时临时暴露。然而，ARM 体系结构的维护操作（Maintenance Operations）存在一个隐蔽缺陷：部分 SoC 的 TLBI（TLB Invalidate）指令和 IC IALLU 序列仅刷新 TLB 而不冲刷页表缓存（PTC, Page Table Cache），导致在异常返回（ERET）后，TTBR1 中残留的中间页表项仍可通过推测执行或预取被用户态感知。攻击者利用性能监控单元（PMU）的精确计数器，在用户态测量内核地址访问的延迟差异，即使 KPTI 已重新隔离页表，仍可通过这些“虚悬的页表”还原内核基址，从而击碎 KASLR。 双重身份页表 两个TTBR ARM64 的虚拟地址空间分为两个区域：0x0000_0000_0000_0000 到 0x0000_FFFF_FFFF_FFFF 为用户空间，0xFFFF_0000_0000_0000 以上为内核空间。当 MMU 进行地址翻译时，根据虚拟地址的最高位自动选择页表基址寄存器：用户地址使用 TTBR0_EL1，内核地址使用 TTBR1_EL1。在未启用 KPTI 的情况下，两个寄存器都指向同一个页表（通常包含内核映射），用户态代码虽不能直接访问内核内存（受页表权限 U/S 位控制），但可以通过侧信道探测 TLB 存在性。 ======================= 正常态：用户空间 (EL0) ======================= CPU 视角： +——————–+ +——————–+ | TTBR0_EL1 (受限表) | —-> | 仅映射：用户空间 | (只读内核映射表) +——————–+ +——————–+…

RISC-V 物理内存保护漏洞

摘要 RISC-V 架构通过物理内存保护与基于页表的虚拟内存两套机制协同控制内存访问。PMP 由机器模式配置，提供物理地址上的粗粒度权限；MMU 由监管者模式管理，实现细粒度的页级保护。然而，RISC-V 特权规范对两者权限叠加规则的定义存在模糊空间——部分微架构实现采用“最严格”策略，部分采用“最宽松”或“时序竞争”策略。攻击者可利用这一裂隙，在 S‑mode 下构造特殊的 PMP 与页表配置组合，使物理内存保护被虚拟内存权限意外覆盖，进而从 S‑mode 提升至 M‑mode 权限等级，读取或篡改安全监控固件。 RISC-V 的两层内存保护 PMP 物理内存保护是 RISC-V 机器模式下的安全基石。PMP 单元由最多 64 个配置寄存器（pmpcfgX）和地址寄存器（pmpaddrX）组成，支持三种地址匹配模式：自然对齐 4 字节区域（NA4）、自然对齐 2 的幂区域（NAPOT）和范围模式（TOR）。每个区域的访问权限由独立的 R（读）、W（写）、X（执行）位控制，并有一个 L（锁定）位。一旦 L 位被置位，PMP 配置对于更低特权级（包括 S‑mode）变为只读，即便 M‑mode 软件也无法修改，除非系统复位。 PMP 检查发生在物理地址完成转换后：当一条 load/store/指令 fetch 请求抵达物理地址总线前，硬件会遍历所有 PMP 条目，找到第一个匹配的区域，并根据访问类型和当前特权级（M、S、U）决定是否允许。若检查失败，对于 load/store 会触发访问错误异常，对于指令 fetch 则产生指令访问错误异常。 MMU RISC‑V S‑mode 通过页表（通常是 Sv39/Sv48 格式）实现虚拟地址到物理地址的转换。页表项包含 U（用户）、R、W、X 位，权限检查发生在翻译阶段。对于 S‑mode…