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…

PAC 绕过新维度

摘要 ARM64 的指针认证通过 PACIA/PACIB 指令为返回地址和函数指针附加密码学签名，阻断了传统 ROP/JOP 攻击。然而，PAC 的密钥分域——指令地址用 A-key，数据地址用 B-key——留下了裂隙。攻击者可以在 JavaScript JIT 编译过程中喷射精心构造的 shellcode，利用 JIT 引擎生成混合了返回指令序列的代码，在指令域签名却在数据域校验，从而绕过 PAC 验证。 ARM64 PAC密钥分域与签名 PAC 指令与密钥 ARMv8.3-A 引入了指针认证（PAC），使用基于 QARMA 的轻量级 MAC 算法为 64 位指针生成认证码，嵌入指针的高位。核心指令： PACIA Xd, Xn：使用指令 A-key 对 Xn 生成签名，存储到 Xd。 PACIB Xd, Xn：使用指令 B-key 对 Xn 签名。 AUTIA Xd, Xn：验证 A-key 签名，若失败则将 Xd 设为无效指针。 AUTIB Xd, Xn：验证 B-key 签名。 A-key 用于指令地址（如返回地址、函数指针），B-key…

Git LFS 指针文件的竞态条件与 Smudge Filter 的隐蔽持久化

摘要 Git Large File Storage 用轻量指针文件替代大文件，再通过 Smudge Filter 在 checkout 时透明下载真实内容。这套机制原本是为了解决版本控制中的大文件管理问题，却在不经意间开辟了一条隐蔽的持久化通道：指针文件仅通过格式校验即可被认定为合法，而 Smudge Filter 在 checkout 时执行的命令完全由仓库内的 .gitattributes 控制。攻击者可以在指针文件通过验证后、实际下载内容完成前的微秒级窗口内，利用竞态条件将恶意载荷替换为“真实”文件，或直接注册一个伪装成 LFS Filter 的恶意 Smudge Filter，在 git clone 的瞬间执行任意命令。 Git LFS信任机制 LFS 指针文件的静态格式 Git LFS 的核心设计理念是“用指针文件替代大文件”。在 Git 仓库中，一个被 LFS 管理的大文件（如 video.mp4）会被替换为如下结构的指针文件： version https://git-lfs.github.com/spec/v1 oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393 size 341283 这个文件仅包含三行文本：版本声明、对象 OID（SHA-256 哈希）、文件原始大小。Git 对 LFS 指针的合法性校验仅基于两点： 第一行匹配version https://git-lfs.github.com/spec/v1。 第二行以oid sha256: 开头，后跟 64 个十六进制字符。 只要满足这两个格式条件，Git 就认为该文件是一个有效的 LFS 指针，并在后续操作中触发…

滥用 Windows KeUserModeCallback 的 Ring-3

摘要 Windows 内核中存在一条鲜为人知的“返魂术”——KeUserModeCallback。它是唯一一种从 Ring-0 主动调用 Ring-3 代码的合法设计机制，在 win32k 处理 GUI 请求时被高频使用。该机制通过 PEB 中存储的 KernelCallbackTable 函数指针表实现回调分发——内核以 ApiNumber 为索引调用表中的回调函数，而该表存储在用户态可写内存中。攻击者一旦获取了 KernelCallbackTable 的写入权限，即可劫持回调函数指针，将控制流重定向至恶意 Shellcode。 KeUserModeCallback 机制全解 NT 4.0架构决策 在 Windows NT 4.0 之前，图形子系统完全运行在用户态。NT 4.0 时期，微软将窗口管理器（Window Manager）和设备无关图形接口（GDI）的主体逻辑迁入内核，形成了 win32k.sys 这一内核态图形驱动。这次架构重组引入了一个此前不存在的需求：内核态的 win32k 需要频繁调用用户态的代码——例如执行应用程序注册的钩子函数、发送事件通知、拷贝应用层数据。 常规的系统调用是 Ring-3 → Ring-0 → Ring-3 的单向流程，而这一新需求要求的是 Ring-0 → Ring-3 → Ring-0 的双向流程——内核主动向用户态发起调用，等待用户态代码执行完毕后将结果返回内核。微软为此实现了“反向系统调用”机制，其核心函数就是由 NT 执行体导出的 KeUserModeCallback。 函数原型与执行限制 KeUserModeCallback 的函数原型如下： NTSTATUS KeUserModeCallback(…

文件系统时间戳的错误

摘要 NTFS并非单一真相源。文件创建、修改、访问时间戳同时存在于MFT的$STANDARD_INFORMATION和$FILE_NAME属性中，且更新规则迥异。USN Journal以变更日志形式记录了每一次文件操作的精确时刻与原因码，$LogFile则以事务日志形式保存了更深层的元数据操作序列。攻击者常利用Timestomping技术篡改$SI时间戳以掩盖入侵时间线，但$FN时间戳、USN Record中的USN_REASON_DATA_OVERWRITE事件以及$LogFile中的重做/撤销记录往往被忽略。这三者在微秒级精度上的不一致，恰构成最坚固的证据链。 NTFS文件系统时间戳架构 $STANDARD_INFORMATION与$FILE_NAME NTFS的核心元素是主文件表（MFT），它存储系统中每个文件的条目。MFT中的每个条目包含许多存储文件描述元数据的属性。其中最为关键的两个属性——$STANDARD_INFORMATION（$SI）和$FILE_NAME（$FN）——各自独立存储着文件的MAC(B)时间戳：M（修改时间）、A（访问时间）、C（MFT变更时间）、B（创建时间）。 $SI属性中的时间戳大致与文件内容的交互相关——当你编辑一个文档、更改其权限或写入数据时，$SI时间戳会被更新。$FN属性中的时间戳则大致与文件位置和名称的交互相关——当你重命名文件、移动文件到另一个目录时，$FN时间戳会被更新。 这种设计上的分歧制造了一个天然的取证双轨系统：同一个文件，在不同的元数据属性中可能存储着不同的时间信息。关键点在于，攻击者通常只修改$STANDARD_INFORMATION中的时间，而忽略$FILE_NAME属性中的副本。 严格地说，修改$SI时间戳是一种极为常见的Timestomping方式，因为可以通过用户层面上的API进行操作——包括Cobalt Strike、Timestomp.exe和Metasploit在内的主流攻击工具都内置了此项功能。然而，修改$FN则需要调用内核API或滥用$FN时间戳的生成方式。已知的$FN篡改手段仅有两个：其一，在未引入Patch Guard的旧操作系统上，使用NtSetInformationFile和NtQueryInformationFile直接写入；其二，在任何操作系统上先篡改$SI，然后移动或重命名文件，Windows会自动将修改后的$SI复制到$FN中。 值得注意的是，在取证分析实践中广泛流传着两个误区：一是认为$FILE_NAME中的时间戳永远不会被篡改，二是认为自动化工具生成的时间戳纳秒部分必定为全零。事实上，高级攻击者完全可以通过上述方法同步修改$FN时间戳，部分经过定制化的工具（如Metasploit的timestomp模块）也支持带纳秒精度的时间戳生成。这要求取证分析师必须超越简单的$SI/$FN比对，深入到USN Journal和$LogFile层面进行交叉验证。 在实际攻击事件中，Timestomping的使用已相当普遍。APT28在入侵后的第一时间即篡改了后门文件的时间戳，APT29（Cozy Bear）在SolarWinds事件中大规模使用时间戳篡改以将其恶意DLL混入合法更新包，Lazarus Group更是直接复制calc.exe的时间戳注入到其恶意投放的文件中——这正是Cobalt Strike内置timestomp模块的标准操作方式。 MFT Record的物理结构 要深入理解上述两类时间戳的差异，必须了解MFT记录的物理结构。 每个MFT记录恰好为1024字节（1 KiB）。前42字节包含FileRecordHeader，紧接着是一系列属性的顺序排列。属性序列以类型为0xFFFFFFFF的结束标记终止。 FileRecordHeader的关键字段包括： 字段 类型 偏移 描述 signature [u8; 4] 0x00 总是 b”FILE” usa_offset u16 0x04 更新序列数组偏移 lsn u64 0x08 $LogFile序列号，用于日志关联 sequence_number u16 0x10 每次记录复用递增 attrs_offset u16 0x14 第一个属性的偏移（通常0x30） flags u16 0x16 标志位：0x01=已分配, 0x02=目录,…

终端隐形链：OSC 8超链接注入攻击

摘要 终端模拟器是现代开发者和系统管理员的日常入口，但很少有人意识到，那串出现在命令行上的蓝色下划线文字，背后承载的远不止一个 URL。OSC 8 超链接转义序列允许终端在纯文本中嵌入可点击的链接，其设计初衷是增强可用性，却意外为攻击者提供了一个从“只读终端”突破到本地资源执行的低成本跳板。 本文深度解析 OSC 8 协议的底层语法、在 Windows / Linux 终端中的注入向量、file:// URI 的跨平台行为差异，以及各操作系统与终端模拟器层层设限的安全机制。最后，我们将在一个微秒级竞赛的视角下，重新审视这类“非代码执行”攻击面在纵深防御体系中的真实威胁等级。 终端噪声 如果你在 GNOME Terminal 或 Windows Terminal 中执行 ls，忽然看到一行“点击此处领取奖励”，并且鼠标真的可以点，你的第一反应是什么？ 多数人会将此归结为“终端的新奇特性”。但从安全角度看，当终端的输出不再是纯文本，而能够嵌入可点击的交互元素时，终端就从“被动显示设备”升级为了“半主动交互界面”。这意味着，原本只能通过社工诱导用户手动复制粘贴执行的攻击，现在可以简化为一次点击。 这就是 OSC 8 超链接转义序列 所带来的根本性攻击面变化。它不是漏洞，而是协议特性——一个被主流终端广泛支持的、允许向输出流中注入点击行为的公开标准。 OSC 8超链接协议 OSC（Operating System Command）是终端控制序列的一族，由 ESC ]（x1b]）引入。OSC 8 专门用于“超链接”，其完整格式为： ESC ] 8 ; params ; uri ST 或者用 BEL（x07）作为终止符： ESC ] 8 ; params ; uri…