当前位置：首页 > news >正文

劫持SUID程序提权彻底理解Dirty_Pipe：从源码解析到内核调试

news 来源：原创 2025/9/13 11:06:20

DirtyPipe（CVE-2022-0847）漏洞内核调试全流程指南

本文主要面向对内核漏洞挖掘与调试没有经验的初学者，结合 CVE-2022-0847——著名的 Dirty Pipe 漏洞，带你从零开始学习 Linux 内核调试、漏洞复现、原理分析与漏洞利用。该漏洞危害极大，并且概念简单明了，无需复杂前置知识即可理解和复现。

文章涵盖以下主要内容：

环境搭建与调试准备：介绍如何编译带调试信息的内核、搭建模拟漏洞的实验环境，以及如何利用 QEMU 和 gdb 进行内核动态调试。
内核源码阅读与调试技巧：详细解析 Linux 系统调用、文件操作与管道机制，讲解如何借助源码阅读和调试技巧来深刻理解内核的工作原理及漏洞成因。
从底层彻底理解dirty_pipe漏洞的利用原理：从管道的页缓存机制、零拷贝技术和相关内核数据结构出发，揭示 Dirty Pipe 漏洞的根本原因以及为何这一漏洞能够实现任意写覆盖。
Dirty_pipe漏洞复现与内核动态调试分析：提供一个完整的漏洞复现流程及示例代码，展示如何利用 pipe 与 page cache 的交互缺陷实现对只读文件的越权覆盖，并通过内核调试验证漏洞利用过程。
解决和解释Dirty_Pipe在复现过程中的疑问：总结漏洞利用过程中常见的问题与疑问，并给出详细的解释和调试技巧，帮助读者理解每一步骤的关键原理与细节。
通过Dirty_pipe劫持劫持SUID二进制文件进行提权：最后讲解如何单独依靠这漏洞进行root提权！

一、调试编译模拟漏洞环境搭建

环境搭建的调试脚本已经上传github：Brinmon/KernelStu

1. 内核准备

源码下载路径：Index of /pub/linux/kernel/v5.x/
编译教程：kernel pwn从小白到大神(一)-先知社区

wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.8.1.tar.gz
tar -xvf linux-5.8.1.tar.gz
cd linux-5.8.1/
sudo apt-get update
sudo apt-get install git fakeroot build-essential ncurses-dev xz-utils qemu flex libncurses5-dev libssl-dev bc bison libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev libelf-dev dwarves zstd
#make menuconfig  命令需要依赖库,下面的
sudo apt-get install libncurses5-dev libncursesw5-dev
make menuconfig #图形化配置配置文件cp .config .config.bak
#避免make 的时候报错,直接将.config内的CONFIG_SYSTEM_TRUSTED_KEYS字段置空不然会报错
sed -i 's/^\(CONFIG_SYSTEM_TRUSTED_KEYS=\).*/\1""/' .config
#还需要给Makefile添加 -0O选项避免编译优化
#最后多核编译就可以了
make -j$(nproc) bzImage

检查勾选配置：

Kernel hacking —> Kernel debugging
Kernel hacking —> Compile-time checks and compiler options —> Compile the kernel with debug info
Kernel hacking —> Generic Kernel Debugging Instruments –> KGDB: kernel debugger
kernel hacking —> Compile the kernel with frame pointers（找不到）
WSL直接编译：

速度嘎嘎快！

2. 文件系统准备

构建最小根文件系统（基于BusyBox）

wget https://busybox.net/downloads/busybox-1.36.0.tar.bz2  
tar -xvf busybox-1.36.0.tar.bz2  
cd busybox-1.36.0  
make defconfig  
make menuconfig  # 选中 "Build static binary (no shared libs)"  
make -j$(nproc) && make install

配置磁盘镜像
配置rcS文件：

#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs devtmpfs /dev
mount -t tmpfs tmpfs /tmp
mkdir /dev/pts
mount -t devpts devpts /dev/ptsecho -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"# 创建文件并设置权限（root可读写，其他用户只读）
echo "This is a secret file!" > /secret.txt
chmod 644 /secret.txt  # 644 = rw-r--r--
chown root:root /secret.txtsetsid cttyhack setuidgid 1000 sh
poweroff -d 0 -f

3. 工具链准备

安装Qemu：

apt install qemu qemu-utils qemu-kvm virt-manager libvirt-daemon-system libvirt-clients bridge-utils

安装pwndbg：

nix profile install github:pwndbg/pwndbg --extra-experimental-features nix-command --extra-experimental-features flakes

gdb.sh

pwndbg -q -ex  "target remote localhost:1234" \-ex "add-auto-load-safe-path /home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1" \-ex "file /home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/vmlinux" \-ex "b /home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/fs/open.c:1184" \ #open打开的文件结构体，查看file \-ex "b /home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/fs/pipe.c:882" \ #pipe创建的管道结构体，查看结构体地址 \-ex "b /home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/fs/pipe.c:536" \ #pipe_write为管道结构体赋予可以合并标记 \-ex "b /home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/mm/filemap.c:1995" \ #splice获取到的文件结构体，查看file \-ex "b /home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/mm/filemap.c:2029" \ #generic_file_buffered_read获取只读文件的page \-ex "b /home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/lib/iov_iter.c:372" \ #文件结构体的page直接替换了管道结构体的page未重新初始化是否可以续写 \-ex "b /home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/fs/pipe.c:463" \ #向管道写入数据，发现可以在管道page续写，但是由于该page实际指向了只读文件的实际page，所以可以实现文件越权写 \-ex "c"

start.sh

#!/bin/sh
qemu-system-x86_64 \-m 128M \-kernel ./bzImage \-initrd  ./rootfs_new.cpio \-monitor /dev/null \-append "root=/dev/ram rdinit=/sbin/init console=ttyS0 oops=panic panic=1 quiet nokaslr loglevel=7" \-cpu kvm64,+smep \-smp cores=2,threads=1 \-nographic \-s

二、Linux内核源码阅读和调试技巧

Linux系统调用syscall源码实现搜索技巧

系统调用实现原理
Linux 系统调用是用户空间与内核交互的核心接口，其实现依赖于架构相关的中断机制（如 x86 的int 0x80或syscall指令）和系统调用表（sys_call_table）。每个系统调用通过唯一的系统调用号索引，对应内核中的sys_xxx函数。例如，open系统调用在内核中对应fs/open.c中的sys_open函数。

添加系统调用号

arch/x86/entry/syscalls/syscall_64.tbl

在linux源码中寻找到这个，手动添加系统调用号！

0	common	read			sys_read

第一列是系统调用号，第二列表示该系统调用适用的架构类型（如common表示通用架构），第三列是系统调用的名称（在用户空间使用的名称），第四列是内核中对应的系统调用实现函数名。若要添加新的系统调用号，需按照此格式在文件中新增一行，并确保系统调用号的唯一性。

声明系统调用
系统调用的声明通常位于include/linux/syscalls.h文件中。以read系统调用为例，其声明如下：

asmlinkage long sys_read(unsigned int fd, char __user *buf, size_t count);

asmlinkage关键字用于指示编译器该函数是从汇编代码调用的，这在系统调用中很常见，因为系统调用的入口点通常由汇编代码处理。函数声明明确了系统调用的返回类型（这里是long）、参数类型及名称。其中，char __user *类型表示指向用户空间内存的指针，用于确保内核在访问该指针时进行必要的安全检查，防止内核非法访问用户空间内存。

定义系统调用
系统调用的实现代码位置较为灵活。若不想修改makefile文件的配置，可将系统调用的实现放置在kernel/sys.c文件中。当然，为了更好的代码组织和管理，系统调用号也可分类放置在不同的文件夹中：
1. 核心系统调用目录
**(1) **kernel/：功能类型：进程管理、信号处理、定时器等核心功能。
**(2) **fs/：功能类型：文件系统操作、文件读写、目录管理等。
**(3) **mm/：功能类型：内存管理、映射、堆分配等。
**(4) **net/：功能类型：网络通信、套接字操作。
**(5) **ipc/ ：功能类型：进程间通信（IPC）。

SYSCALL_DEFINE 宏解析,系统调用号实现的具体，SYSCALL_DEFINE** 宏** 的书写规范与核心规则：

// 使用SYSCALL_DEFINEx宏（x=参数个数），x：参数数量（1~6）
// name：系统调用名称（用户态调用的名称，如 read）。
// 参数书写格式:每个参数需明确类型和变量名。用户空间指针必须标记 __user（如 char __user *, buf）
// 参数名称和参数类型要分别作为宏定义的一个参数！
SYSCALL_DEFINEx(name, type1, arg1, type2, arg2, ...)
{
....
}

根据这个方法可以找到read系统调用的函数实现：

grep -r "SYSCALL_DEFINE3(read,.*"

动态调试定位f_op文件结构体的操作函数源码

f_op 结构体原理
struct file_operations（简称f_op）定义了文件操作的函数指针，如open、read、write等。内核通过file->f_op调用这些函数，具体实现由文件系统（如 ext4、NFS）或设备驱动提供。

例如，在 ext4 文件系统中，当用户空间执行open操作打开一个文件时，内核会根据该文件对应的file结构体中的f_op指针，找到并调用 ext4 文件系统中定义的open操作函数。这个函数会处理诸如检查文件权限、打开文件描述符等具体操作。在设备驱动场景下，对于块设备驱动，其f_op中的read和write函数会负责与硬件设备进行数据交互，将数据从设备读取到内核缓冲区或从内核缓冲区写入设备。
可以查看一下write的源码实现发现调用了，file->f_op->write_iter函数但是无法找到其源码实现！

下面结合源码进行讲解。假设我们要分析ext4文件系统中read操作的f_op函数实现。首先，在fs/ext4/file.c文件中，可以找到ext4_file_operations结构体的定义：

#/home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/fs/ext4/file.cconst struct file_operations ext4_file_operations = {.llseek		= ext4_llseek,.read_iter	= ext4_file_read_iter,.write_iter	= ext4_file_write_iter,.iopoll		= iomap_dio_iopoll,.unlocked_ioctl = ext4_ioctl,
#ifdef CONFIG_COMPAT.compat_ioctl	= ext4_compat_ioctl,
#endif.mmap		= ext4_file_mmap,.mmap_supported_flags = MAP_SYNC,.open		= ext4_file_open,.release	= ext4_release_file,.fsync		= ext4_sync_file,.get_unmapped_area = thp_get_unmapped_area,.splice_read	= generic_file_splice_read,.splice_write	= iter_file_splice_write,.fallocate	= ext4_fallocate,
};

这里，.read_iter成员指向了ext4文件系统中read操作的具体实现函数ext4_file_read_iter。当用户空间执行read系统调用时，内核在处理过程中，若涉及到ext4文件系统的文件，就会通过file->f_op->read_iter来调用ext4_file_read_iter函数，从而完成read操作的具体功能，如从磁盘读取数据并填充到用户提供的缓冲区中。

GDB动态调试定位f_op 结构体所使用的函数
定位一下：pipe_buf_confirm函数

在源码下完断点之后，来到该调用的位置，在使用gdb命令就饿可以定位到buf->ops的具体值，从而在源码中定位函数的具体实现！

#/home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/fs/pipe.c
static const struct pipe_buf_operations anon_pipe_buf_ops = {.release	= anon_pipe_buf_release,.try_steal	= anon_pipe_buf_try_steal,.get		= generic_pipe_buf_get,
};

Linux内核源码结合AI进行动态调试分析技巧

编译完成内核之后，可借助 AI 工具为内核源码添加代码注释，但需注意不能改变 Linux 源码的结构。由于动态调试时是直接索引到源码，如果改变源码的代码行数或者增加过多文本数量，都会打乱调试时的源码定位。因此，在使用 AI 添加提示词时，应将注释加在每行代码的后面。

常用的提示词,也可以自己优化:

给代码添加中文注释，只在每行代码的后面添加中文注释，如果遇到已有的注释则不修改:
{
}

在使用gdb调试源码时，常用的命令如下：

n ：执行下一行源码，但不进入函数内部（如果当前行有函数调用）。
ni ：执行下一条汇编指令，同样不进入函数内部（若当前指令涉及函数调用）。
s ：进入当前行调用的源码函数内部，便于深入调试函数实现。
si ：进入call调用的函数内部，且以汇编指令级别的方式进行单步调试。

为了让gdb能正确索引到内核源码，需要修改.gdbinit文件添加源码索引。例如：

set disassembly-flavor intel 
dir /home/ub20/LibcSource/glibc-2.31/

set disassembly-flavor intel命令设置gdb的反汇编风格为 Intel 格式，这样在调试时显示的汇编代码更易阅读。

三、从底层彻底理解dirty_pipe漏洞的利用原理

syscall pipe : Linux 中的管道Pipe是什么?

在 Linux 系统中，pipe是一种进程间通信（IPC，Inter-Process Communication）机制。它允许两个或多个进程通过一个共享的缓冲区来传递数据，实现进程之间的通信。从系统调用的角度来看，通过pipe系统调用可以创建一个管道。

在终端中输入man 2 pipe可以查看其详细手册:

讲解系统调用函数pipe的源码实现

当调用pipe系统调用时，它会在内核中创建一个管道对象，并返回两个文件描述符，一个用于写入（通常称为写端，fd[1]），另一个用于读取（通常称为读端，fd[0]）。数据从写端写入管道，然后可以从读端读取出来，遵循先进先出（FIFO，First-In-First-Out）的原则。

grep -r "SYSCALL_DEFINE1(pipe.*"   #注释SYSCALL_DEFINE后门的数字代表参数的数量，第一个参数为系统调用号的名称！

从内核代码角度看，pipe系统调用的定义如下：

SYSCALL_DEFINE1(pipe, int __user *, fildes)
{return do_pipe2(fildes, 0);
}

这里的SYSCALL_DEFINE1宏定义了一个接受一个参数的系统调用，该参数fildes是一个指向用户空间数组的指针，用于存储返回的文件描述符。实际的管道创建工作由do_pipe2函数完成：

/** sys_pipe() is the normal C calling standard for creating* a pipe. It's not the way Unix traditionally does this, though.*/
static int do_pipe2(int __user *fildes, int flags)
{struct file *files[2];int fd[2];int error;error = __do_pipe_flags(fd, files, flags);if (!error) {if (unlikely(copy_to_user(fildes, fd, sizeof(fd)))) {fput(files[0]);fput(files[1]);put_unused_fd(fd[0]);put_unused_fd(fd[1]);error = -EFAULT;} else {fd_install(fd[0], files[0]);fd_install(fd[1], files[1]);}}return error;
}

do_pipe2函数首先调用__do_pipe_flags来创建管道，并获取两个文件描述符。如果创建成功，它会尝试将这两个文件描述符复制到用户空间的fildes数组中。若复制失败，函数会清理已分配的资源并返回错误。

进一步深入内核实现，__do_pipe_flags函数会调用create_pipe_files，最终调用到get_pipe_inode函数，该函数负责创建管道的核心数据结构：
可以追踪到系统调用链：do_pipe2->__do_pipe_flags->create_pipe_files->get_pipe_inode

#/home/ub20/KernelStu/KernelEnvInit/linux-5.8.1/linux-5.8.1/fs/pipe.c
static struct inode * get_pipe_inode(void)
{struct inode *inode = new_inode_pseudo(pipe_mnt->mnt_sb);struct pipe_inode_info *pipe;
...pipe = alloc_pipe_info();//申请一个结构体if (!pipe)goto fail_iput;inode->i_pipe = pipe;pipe->files = 2;pipe->readers = pipe->writers = 1;inode->i_fop = &pipefifo_fops;
...
}

get_pipe_inode函数主要完成以下几个关键步骤：

创建伪文件系统（pipefs）中的 inode：通过new_inode_pseudo函数创建一个属于pipefs文件系统的inode，该inode代表了管道对象在内核中的存储节点。
分配管道核心结构体：调用alloc_pipe_info函数分配一个pipe_inode_info结构体，该结构体包含了管道的状态信息，如读写计数器、缓冲区指针等。
初始化管道读写计数器：将pipe->readers和pipe->writers初始化为 1，表示管道的读写端都已准备就绪。

讲解Linux管道Pipe在内核中的管理机制

在Linux内核中，管道（Pipe）通过struct pipe_inode_info和struct pipe_buffer两个核心结构体实现进程间通信（IPC）的底层管理。

1. 环形缓冲区与指针管理

struct pipe_inode_info {
...unsigned int head;             // 环形缓冲区写指针unsigned int tail;             // 环形缓冲区读指针unsigned int max_usage;unsigned int ring_size;
...struct page *tmp_page;         // 临时页缓存（用于零拷贝优化）
...struct pipe_buffer *bufs;      // 管道缓冲区数组（核心！）
...
};

在内核实现中，管道缓存空间总长度一般为 65536 字节，以页为单位进行管理，总共 16 页（每页大小为 4096 字节）。这些页面在物理内存中并不连续，而是通过数组进行管理，从而形成一个环形链表。其中，维护着两个关键的指针：

head：指向最新生产的缓冲区位置，即数据写入的位置。
tail：指向开始消费的缓冲区位置，即数据读取的位置。
max_usage：表示管道中可使用的最大缓冲区槽位数。
ring_size：管道缓冲区的总数，通常是 2 的幂次方，默认情况下，Linux 内核中管道的缓冲区数量为 16 个（PIPE_DEF_BUFFERS）。
tmp_page：用于缓存已释放的页面。
bufs：是一个循环数组，用于管理管道缓冲区。每个缓冲区的大小为一页（在常见的系统中，一页大小默认是0x1000字节）。

2. 内存页与缓冲区数组

struct pipe_buffer {struct page *page;          // 直接指向物理内存页（漏洞利用目标unsigned int offset, len;//页内偏移，有效数据长度const struct pipe_buf_operations *ops; // 操作函数表unsigned int flags;         // 状态标志unsigned long private;      // 私有数据
};

管道数据存储在离散的物理内存页中，通过struct pipe_buffer数组（bufs）管理：

bufs数组：数组中的每个元素对应一个内存页（struct page），通过page字段直接指向物理页帧。这样，内核可以直接定位到存储管道数据的物理内存位置。
非连续内存管理：页之间无需连续，内核通过数组索引实现逻辑上的环形链表。这种非连续内存管理方式，充分利用了内存空间，避免了因连续内存分配困难而导致的资源浪费。在进行数据读写时，内核根据head和tail指针在bufs数组中的索引，找到对应的缓冲区进行操作，同时通过环形链表的逻辑，实现数据的循环读写。例如，当head指针到达数组末尾时，下一次写入会回到数组开头，继续填充缓冲区。

管道本质是一个由内核维护的环形缓冲区，通过head和tail指针实现高效的数据读写：
可以看一个Pipe缓冲区的实际示意图：

这张图片展示了一个 pipe 的基本数据结构，具体是如何通过循环缓冲区（circular buffer）来管理数据传输。

或者参考一下这个结构图:

pipe->bufs[0]** 到 pipe->**bufs[15]：这是管道的 16 个缓冲区，每个缓冲区对应一个 pipe_buffer 结构体。
pipe->tail 和 pipe->head：pipe->tail 指向当前读取位置，pipe->head 指向当前写入位置。缓冲区中的黄色区域表示当前正在被使用的缓冲区（inuse），即当前正在读取或写入的部分。
页面管理：每个 pipe_buffer 结构体对应一个 4KB 的页面，图中显示了这些页面的分布情况，并标记了哪些部分是正在被使用的。

讲解Linux管道Pipe如何进行数据写入和读取

当我们使用read和write向pipe进行数据写入和读取的时候,read和write会寻找到pipe_write和pipe_read进行数据写入和读取!
根据前面的管道结构体的讲解可知,pipe_write和pipe_read进行数据操作的时候实际都是对pipe->buf的内容进行写入和读取!

pipe_write写入流程

数据写入管道的操作由内核中的pipe_write函数负责。在数据写入过程中，pipe_write会调用copy_page_from_iter函数来完成从用户空间到内核管道缓冲区的实际数据复制。下面对pipe_write函数的执行流程进行详细拆解：

static ssize_t
pipe_write(struct kiocb *iocb, struct iov_iter *from)
{struct file *filp = iocb->ki_filp;  // 获取文件指针struct pipe_inode_info *pipe = filp->private_data;  // 获取管道信息
...head = pipe->head;                 // 获取当前头指针
...if ((buf->flags & PIPE_BUF_FLAG_CAN_MERGE) &&  // 检查缓冲区是否可合并
...ret = copy_page_from_iter(buf->page, offset, chars, from);  // 复制数据到缓冲区
...struct pipe_buffer *buf = &pipe->bufs[head & mask];  // 获取当前缓冲区
...pipe->head = head + 1;  // 移动头指针...buf = &pipe->bufs[head & mask];  // 获取新缓冲区buf->page = page;    // 设置缓冲区页buf->ops = &anon_pipe_buf_ops;  // 设置缓冲区操作buf->offset = 0;     // 设置偏移量buf->len = 0;        // 初始长度为0
...if (is_packetized(filp))  // 如果是数据包模式buf->flags = PIPE_BUF_FLAG_PACKET;  // 设置数据包标志elsebuf->flags = PIPE_BUF_FLAG_CAN_MERGE;  // 设置可合并标志pipe->tmp_page = NULL;  // 清空临时页
...copied = copy_page_from_iter(page, 0, PAGE_SIZE, from);  // 复制数据到页
...return ret;               // 返回实际写入的字节数
}

写入流程：数据按页写入bufs[head]，更新head指针；若缓冲区满，写进程进入睡眠。
在pipe_write函数写入数据过程中，获取管道的写指针head，通过head & mask的运算，在pipe->bufs数组中定位当前用于写入的缓冲区buf。这里的mask是根据管道缓冲区总数计算得出的掩码，用于实现环形缓冲区的循环访问。最后调用copy_page_from_iter函数，将用户空间的数据从from迭代器中复制到内核分配的页面中，完成数据写入操作。

写入标记：

            if (is_packetized(filp))  // 如果是数据包模式buf->flags = PIPE_BUF_FLAG_PACKET;  // 设置数据包标志elsebuf->flags = PIPE_BUF_FLAG_CAN_MERGE;  // 设置可合并标志

可以发现这里当第一次向管道写入数据的时候会将pipe->bufs[i]->flags字段赋值为PIPE_BUF_FLAG_CAN_MERGE,如果是网络数据通过pipe传输的话就会赋值PIPE_BUF_FLAG_PACKET;

        if ((buf->flags & PIPE_BUF_FLAG_CAN_MERGE) &&  // 检查缓冲区是否可合并
...ret = copy_page_from_iter(buf->page, offset, chars, from);  // 复制数据到缓冲区

如果想继续在管道写入数据会首先检查buf->flags字段和buf->page是否有剩余空间,再次调用pipe_write可以继续向这个buf->page写入数据!