今年的 ccb&ciscn 初赛有一道 Linux 内核的 Pwn 题，让我这个内核菜鸡被直接“硬控”了。现在初赛都上内核了。。。

赛后搞到了 WP，于是正好趁着元旦假期有时间好好复现一下，分析了一下这道题的利用技术的原理，于是就有了这篇文章。

modprobe_path覆盖利用技术是一种 Linux 内核漏洞利用方法，它可以让攻击者以 root 权限运行任意 shell 脚本。

modprobe_path覆盖利用技术的关键是覆盖掉modprobe_path内核全局变量，它的默认值为/sbin/modprobe程序的路径，modprobe是一个用于向 Linux 内核添加可加载内核模块，或从内核中移除可加载内核模块的工具。本质上它是一个用户态程序，当我们在 Linux 内核中安装或卸载新模块时会被执行。

我们可以通过运行以下命令检查：

modprobe_path变量中的程序，会在我们执行一个系统无法识别文件类型的非法格式文件（无效魔数）时被调用。简单说一般我们执行 shell 文件时文件签名是#!/bin/bash，这是合法的文件格式，系统可以识别。而我们执行一个文件签名为\xff\xff\xff\xff的文件时内核会进行一系列操作，最终触发并以 root 权限执行modprobe_path变量中的程序。

因此如果我们将modprobe_path变量覆盖修改为想要执行的程序，然后再执行一个非法格式文件就可以以 root 权限执行我们想要执行的目标程序。

但是如果内核开启了CONFIG_STATIC_USERMODEHELPER内核配置选项，那么会将内核执行用户态 helper 的路径从运行时可变的全局变量改为编译期固定的常量，这样我们就无法对modprobe_path进行覆盖修改。

总结一下modprobe_path覆盖利用技术需要满足以下条件：

基本上，在大多数的 kernel pwn 题目中，条件 2 和条件 3 都是直接满足的，因此最关键的问题在于是否具备任意地址写的能力以及内核是否开启了CONFIG_STATIC_USERMODEHELPER选项。

询问了一下 GPT 给了一个检查内核是否开启CONFIG_STATIC_USERMODEHELPER选项的方法：

如果修改成功则CONFIG_STATIC_USERMODEHELPER选项未开启，不成功则开启。

接下来我们通过分析 Linux 内核的源代码，详细了解覆盖modprobe_path利用技术的原理。

当我们在 Linux Shell 中执行命令时（例如bash中执行ls），本质上会由 Shell 程序内部调用execve系统调用来加载并执行对应的程序。

execve系统调用会设置可执行文件路径、命令行参数数组以及环境变量数组等信息，然后调用do_execve，它才是真正负责执行程序加载的核心函数。

do_execve函数会对传入的可执行文件路径、参数数组和环境变量数组进行封装与处理，然后将执行流程统一转交给 do_execveat_common，由后者完成后续的程序加载与执行逻辑。

do_execveat_common负责构建并填充 linux_binprm，完成命令行参数和环境变量的准备工作。

linux_binprm是 Linux 内核中 描述一个即将被execve执行的可执行文件及其执行上下文的核心数据结构，是execve执行流程中的“载体”，保存了程序加载所需的全部信息。

do_execveat_common最终会调用bprm_execve，进入真正的二进制加载流程。bprm_execve是execve执行路径中最关键的通用入口函数。

bprm_execve函数会先对被加载程序的信息准备凭证与安全检查，最后调用exec_binprm函数加载可执行文件。

exec_binprm函数负责在执行过程中选择并执行合适的二进制格式处理器，通过循环解析解释器链，最终完成可执行文件的确定并触发执行成功事件通知。

其中最重要的逻辑就是解析选择合适的二进制格式处理器部分，因此我们接下来需要跟进search_binary_handler函数分析。

search_binary_handler函数会在formats链表中寻找合适的文件加载器。formats是一个包含所有已注册的可执行格式文件解析器。

常见的解析器：

每种解析器包含一个关键字段load_binary，其中包含着对应格式的加载函数。

检查文件魔数，匹配解析器：

例如 ELF 格式：

如果成功匹配到解析器，内核将调用该格式对应格式的加载函数完成可执行文件的加载（如 ELF 文件或 shell 文件）。

如果没有匹配到解析器，且文件的前 4 字节不可打印（非 ASCII），内核会进入一个兜底处理流程。在在该流程中，内核会根据可执行文件头部的魔数值，动态请求加载对应的 binfmt 内核模块。具体做法是从文件头的第 3、4 字节读取一个 16 位数值，并将其格式化为模块名 binfmt-xxxx，随后调用request_module触发模块加载：

request_module其实是一个宏，真正执行的是__request_module函数：

__request_module函数最终会调用call_modprobe函数。

call_modprobe是内核模块自动加载路径中真正执行用户态程序的函数：

这部分代码的关键点：

通过call_usermodehelper_setup封装好execve需要的所有信息，然后调用call_usermodehelper_exec函数以 root 权限执行modprobe_path的值。

默认的modprobe_path值是：

CONFIG_MODPROBE_PATH来自内核配置，默认为/sbin/modprobe。

所以如果我们修改了modprobe_path的值，并执行一个非法格式文件后就会执行modprobe_path的值。

前面已经说过启用CONFIG_STATIC_USERMODEHELPER选项就会导致modprobe_path覆盖利用技术失效，这里结合代码分析一下原因。

在call_usermodehelper_setup中，如果CONFIG_STATIC_USERMODEHELPER配置选项启用，那么就会执行以下代码：

此时内核会强制使用静态、编译时写死的路径，而忽略modprobe_path，从而使得modprobe_path覆盖技术失效。

下载题目：8aaK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6H3j5h3&6Q4x3X3g2T1j5h3W2V1N6g2)9J5k6h3y4G2L8g2)9J5c8Y4y4Q4x3V1j5I4j5Y4V1J5f1V1q4Q4x3X3c8U0f1U0c8%4y4W2c8m8x3g2y4a6j5h3V1J5N6s2y4m8i4K6y4r3M7s2N6V1i4K6y4p5j5%4j5#2k6l9`.`.

题目提供了三个文件：

首先分析启动脚本：

保护机制：

只读数据保护关闭会导致.rodata段可写，这样的话即使modprobe_path是常量，也能被覆盖。这样就直接绕过了CONFIG_STATIC_USERMODEHELPER的防护。

然后解压rootfs.cpio分析文件系统

在init启动脚本中发现内核加载了babydev.ko内核模块，并在后台运行eatFlag程序。

ida 逆向分析eatFlag程序发现它会在程序启动时读取/flag的内容并存放在堆内存中，然后删除该文件。所以我们只能从eatflag程序的堆内存中读取到 flag。

flag指针是固定地址，很明显程序是没有开启 PIE 的，所以可以从flag指针读取 flag 的值。

接着 ida 逆向分析babydev.ko模块，查看函数表的函数，其中__pfx_开头的是内核在符号层面生成的前缀符号。

接下来首先分析init_module函数，它是内核模块加载入口。

init_module函数初始化了一个名为noc的字符设备，创建了/dev/noc供用户态交互，并分配了一个约 64KB 的全局内核堆缓冲区 global_buf。

发现内核地址泄露漏洞：

由于dest变量在站的布局之后就是v11变量。所以copy_to_user复制 40 字节的数据到用户态会将v11的值也给复制到用户态。

我们可以通过访问这个ioctl接口获取到泄露的数据。

dev_open在设备首次打开时分配一块内核堆内存，记录当前进程的 PID 和进程名，并将该堆指针保存到file->private_data，同时通过全局标志限制设备只能被单次打开。

函数中的v4变量是当前文件偏移，v6变量是实际写入长度。

当v4 + a3 > 0x10000时，驱动试图通过v6 = -*a4截断写入长度，但由于v6为无符号整型，该赋值触发了 signed 到 unsigned 的隐式转换，导致 v6 变成一个极大的正数。

随后该长度被直接用于copy_from_user，且写入地址由 global_buf + data_start + f_pos计算，在缺乏完整边界检查的情况下，最终形成可控偏移、可控长度的内核堆越界写漏洞。

dev_read根据file->f_pos从global_buf的有效数据区向用户态拷贝数据，并在读完后推进文件偏移，逻辑等价于一个简单的内存文件读取实现。

该函数实现了设备的lseek操作（偏移定位），根据a3参数的值选择模式。如果a3为 1 则新位置为当前文件指针加上a2偏移参数。如果a3为 2 则新位置为文件末尾加上偏移。如果a3参数为 3，则新位置等于偏移。

通过这个函数我们可以控制文件偏移配合dev_write函数进行越界写利用。

在关闭设备文件时原子递减打开计数并释放filp->private_data。

cleanup_module在模块卸载时释放init_module中申请的内核资源。

modprobe_path覆写：

将exp放入文件系统并重打包。

然后修改启动脚本加载的文件系统为exp.cpio：

执行exp然后成功拿到 flag：

最后附上一个打远程的脚本：

由于这个补丁被合并到上游内核，导致覆盖modprobe_path这个利用方法在新版本内核中作废了。

Linux 内核利用技术：覆盖modprobe_path - Midas 的博客
复兴modprobe_path技术：克服search_binary_handler（）补丁 - Theori BLOG

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！