文档网络安全教程【免费下载链接】ctf-wikiCome and join us, we need you!项目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki点击查看免费下载在 Linux 内核 pwn如 ctf-wiki 项目 Linux 内核模式 pwn 板块中内核态与用户态之间的访问隔离是攻击者提权路径上的关键防线。本文以 ctf-wiki 仓库中 用戶數據不可訪問 文档为骨架系统讲解 x86 体系下 SMAPSupervisor Mode Access Protection管理员模式访问保护的硬件原理、开启与关闭方法、状态检测手段以及内核 pwn 实战中最常用的两种绕过思路修改 CR4 寄存器与利用copy_from_user/copy_to_user并顺带介绍 ARM 架构的对应机制 PAN。读完本文你将能够在 qemu 与 grub 两种环境下自如控制 SMAP 状态并理解其在ret2usr、栈迁移、内核 ROP 等攻击场景中的实际影响。为什么需要保护用户态数据不可访问Linux 的经典隔离模型默认规定用户态ring 3不可直接访问内核态ring 0的数据、执行内核态的代码这是内核安全的基本盘。但反向的隔离并非一开始就存在——内核对用户态内存的访问与执行在很长一段时间内都是不受限的。正因如此早期内核 pwn 中广泛流行ret2usr攻击手法攻击者在内核态劫持控制流后可以直接ret跳转回用户态构造的代码例如提前构造好的commit_creds(prepare_kernel_cred(NULL))函数指针来完成提权因为此时 CPU 仍处于 ring 0执行用户态代码不会受到任何阻拦。关于该手法的完整介绍可参考 ctf-wiki 中的 ret2usr.md。针对执行用户态代码的漏洞x86 提出了SMEP而针对访问用户态数据的漏洞则提出了本文的主角SMAP。两者的威胁模型并不完全相同若内核态可以执行用户态代码攻击者可以劫持控制流后直接ret到用户态 Shellcode / 函数指针这是 SMEP 解决的问题参见姊妹篇 用戶代碼不可執行若内核态可以访问读写用户态数据攻击者即使不跳转代码也可以通过栈迁移stack pivot把内核栈切换到用户态内存中然后在用户态布置 ROP 链以内核态特权执行 ROP gadget 实现提权这正是 SMAP 要封堵的攻击路径。从 ctf-wiki 的 user-kernel 隔离机制总览 可以看到完整的四层防护体系默认的用户态不可访问内核、SMEP内核态不可执行用户态代码、SMAP内核态不可访问用户态数据、KPTI用户态不可见内核页表 / 模拟执行防护。SMAP 是其中承上启下的关键一环且与 KPTI 存在联动关系——在开启 KPTI 的内核中x86_64 的内核页表会把用户空间映射标记为不可执行模拟 SMEP 效果但SMAP 的不可访问语义并不会被 KPTI 自动模拟因此理解 SMAP 自身仍然必要详见 KPTI 文档。x86 体系下的 SMAPCR4 寄存器第 21 位SMAP 是 x86 架构的硬件特性其开关状态记录在CR4 控制寄存器中CR4 寄存器的第 21 位用于标记是否开启 SMAP 保护1 表示开启0 表示关闭。与之相邻的第 20 位则对应 SMEP。注意原文档此处存在笔误将第 21 位描述为 SMEP结合图中位定义第 20 位 SMEP、第 21 位 SMAP可确认第 21 位实为 SMAP。发展历史与实现原文档中该部分标注为 TODO尚未展开。可以明确的是SMAP 与 SMEP 一样属于硬件级防护需要 CPU 与内核的共同支持CPU 提供 CR4 位与页表访问检查逻辑Linux 内核在启动阶段检测 CPU 能力并把 smap 标志写入/proc/cpuinfo的 flags 中。从 bypass-smep.md 给出的真实运行输出可以看到smap与smep会同时出现在 flags 列表里与pti等标志并列这为我们下面的状态检测提供了依据。开启与关闭 SMAP默认状态与内核命令行参数默认情况下只要 CPU 支持SMAP 保护在内核启动后即处于开启状态。在 CTF 场景中我们通常使用 qemu 启动自定义内核可以通过内核命令行-append选项显式控制# 开启 SMAP qemu-system-x86_64 \ -kernel ./bzImage \ -initrd ./rootfs.cpio \ -append consolettyS0 root/dev/ram oopspanic panic1 smap \ -cpu kvm64,smap \ --nographic # 关闭 SMAP qemu-system-x86_64 \ -kernel ./bzImage \ -initrd ./rootfs.cpio \ -append consolettyS0 root/dev/ram oopspanic panic1 nosmap \ --nographic其中-append中的smap/nosmap是内核命令行参数-cpu后的smap则是让 qemu 模拟的 CPU 暴露该特性-cpu qemu64-v1,smep,smap这种写法在 ctf-wiki 的例题 bypass-smep.md 中可以看到完整用法。建议两者配合使用否则即便内核参数开启模拟 CPU 若不支持该特性也无法生效。通过 grub 在真实系统上关闭 SMAP如果是真实主机可以在 grub 配置/etc/default/grub的两行内核命令行中添加nosmapGRUB_CMDLINE_LINUX_DEFAULTquiet nosmap GRUB_CMDLINE_LINUXinitrd/install/initrd.gz nosmap然后执行update-grub并重启系统即可关闭 SMAP。同理若要开启把nosmap换成smap即可。状态查看grep smap /proc/cpuinfo在启动后的系统qemu 中或宿主机里可以用一条命令确认 SMAP 是否生效grep smap /proc/cpuinfo若输出中出现了smap字符串说明 SMAP 保护已开启否则未开启。参照 bypass-smep.md 中的真实输出/proc/cpuinfo的 flags 形如flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx ... smep ... smap intel_pt ...smep、smap、pti都出现在该列表中即代表对应防护开启。Attack SMAP两种主流绕过思路即使开启了 SMAP攻击者在内核态劫持控制流后依然有两条经典路径可以访问用户态数据直接改写 CR4 寄存器关闭防护以及借助copy_from_user/copy_to_user这类内核导出函数临时豁免访问限制。思路一修改 CR4 寄存器关闭 SMAP与 SMEP 一并关闭CR4 寄存器是软件可写的只要把其第 21 位置 0内核态即可重新访问用户态数据。实践中为了同时解除 SMEP 与 SMAP 的束缚因为后续的ret2usr通常既需要执行用户态代码也需要访问用户态数据普遍采用固定值0x6f0直接覆写 CR4——这个值恰好把第 20、21 位SMEP、SMAP都清成 0是社区常用的关防护通用值。从源码视角看内核中所有修改 cr4 的代码最终都会归结到native_write_cr4函数。因此当攻击者能够劫持控制流后只需在内核空间寻找能够写 CR4 的 gadget 即可。除了直接搜索mov cr4, ...类 gadget 外内核自身也天然存在若干固定的写 CR4 代码路径例如refresh_pce函数、set_tsc_mode函数等——这些函数内部会调用native_write_cr4来刷新 CR4 中的特定控制位攻击者可以复用这些代码片段把写 CR4变成 ROP 链中的一个可调用函数。在 bypass-smep.md 的 2018 强网杯 core 例题中展示了完整且可直接套用的 gadget 组合; 读 CR4 到 rax同时顺带调整栈 MOV_RAX_CR4_ADD_RSP_8_POP_RBP_RET ; 用 0xffffffffffcfffff 屏蔽 SMAP(21) 与 SMEP(20) 两位与运算 POP_RDI_RET ; rdi 0xffffffffffcfffff AND_RAX_RDI_RET ; 写回 CR4 MOV_CR4_RAX_PUSH_RCX_POPFQ_RET该例题的 qemu 启动参数为-cpu qemu64-v1,smep,smap即在同时开启 SMEP 与 SMAP 的环境下通过上述 ROP 链把 CR4 中两位一并清除后再执行ret2usr最终利用swapgs_restore_regs_and_return_to_usermode返回用户态获取 root shell。整套 exp 的构造细节含 canary 泄漏、ROP 链布局可直接阅读 bypass-smep.md。补充一个调试细节gdb 无法直接查看 CR4 寄存器的值通常在内核 crash 时的寄存器 dump 中才能看到因此在构造关闭 SMAP/SMEP 的 ROP 时社区普遍采用固定值0x6f0即mov cr4, 0x6f0来避免不确定性。思路二利用 copy_from_user / copy_to_user 临时豁免除了粗暴关防护内核还提供了按需临时豁免的接口copy_from_user与copy_to_user。这两个函数在实现上会临时清空禁止访问用户态内存的标志在 x86 上即 STAC/CLAC 指令控制 AC 标志位配合 SMAP 的 AC 位机制实现访问豁免完成拷贝后恢复。因此在劫持控制流后攻击者可以直接调用这两个内核函数来读写用户态内存而不需要改动 CR4。这种手法在无法轻易找到写 CR4 gadget、或希望保持防护状态不被察觉的场景下非常实用其代价是需要正确构造函数调用参数目标地址、源地址、长度一般通过 gadget 完成参数传递后调用即可。ARM 体系下的对应机制PANSMAP 在 ARM 架构上的对应物是PANPrivileged Access Never特权访问禁止。与 x86 的 SMAP 类似PAN 同样用于禁止内核态特权模式访问用户态数据。原文档中 ARM-PAN 部分同样标注为 TODO尚未展开细节从机制对应关系看其防护语义与 x86 SMAP 一致在 ARM 内核 pwn 中绕过思路也类似修改相关控制位或利用内核提供的用户访问辅助函数。与 SMEP、KPTI 的联动小结把 ctf-wiki 的 user-kernel 隔离机制 中的四层防线放到一起看攻击与防护的博弈逻辑非常清晰防护机制保护目标硬件/软件载体绕过思路默认隔离用户态不可访问内核态数据特权级检查借助内核自身漏洞提升权限SMEP内核态不可执行用户态代码CR4 第 20 位x86修改 CR4、ROP 链提权、KPTI 联动SMAP内核态不可访问用户态数据CR4 第 21 位x86/ PANARM修改 CR4、copy_from/to_userKPTI用户态不可见内核页表页表隔离x86_64修改页表权限、SWITCH_TO_USER_CR3_STACK、signal handler尤其值得留意的是 KPTI 带来的语义变化在开启 KPTI 的 x86_64 内核中用户空间映射在内核页表中被标为不可执行因此没有 SMEP 的硬件也能获得类 SMEP 效果但 SMAP 的不可访问并未被 KPTI 模拟内核仍可访问用户态内存详见 KPTI 文档。这意味着在现代内核中ret2usr已基本成为历史ret2usr.md 明确给出了这一结论但针对 SMAP 的栈迁移 内核 ROP 思路依然活跃在 CTF 与真实漏洞利用中。参考与延伸阅读本文主体ctf-wiki 的 用戶數據不可訪問SMAP姊妹篇用戶代碼不可執行SMEP、KPTI 机制实战例题SMEPSMAP 双开环境下的完整 ROP 绕过bypass-smep.md攻击面背景未开启 SMAP/SMEP 时的经典手法ret2usr.md内核环境搭建qemu 启动、内核编译等environment 目录赞分享文档网络安全教程【免费下载链接】ctf-wikiCome and join us, we need you!项目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki点击查看免费下载相关推荐gh_mirrors/li/linux内核系统调用过滤seccomp配置与使用gh_mirrors/li/linux内核系统调用过滤seccomp配置与使用 引言你还在为容器逃逸、恶意程序滥用系统调用而烦恼吗 在云原生与容器化时代操作系统内核驱动驱动开发虚拟化嵌入式网络存储ctf-wiki 内核安全入门Linux Kernel Pwn 基础知识全景特权级、系统调用、权限管理与防护机制ctf wiki 内核安全入门Linux Kernel Pwn 基础知识全景特权级、系统调用、权限管理与防护机制 本文是 ctf wiki 仓库 内核模式文档网络安全教程Linux内核引导过程第五部分内核解压缩详解Linux内核引导过程第五部分内核解压缩详解 前言 本文是Linux内核引导过程系列文章的第五部分我们将深入探讨内核解压缩的关键环节。在前一篇文章中我文档教程操作系统上一篇Eta在JVM上启航的现代Haskell之旅下一篇技术债务评估实战基于 agentic-awesome-skills 中 brooks-debt 技能的六维风险扫描与 Pain × Spread 优先级模型创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考