【51CTO專稿】本文將詳細介紹Android中的防緩沖區(qū)溢出技術(shù)的來龍去脈。

1、什么是ASLR？

ASLR（Address space layout randomization）是一種針對緩沖區(qū)溢出的安全保護技術(shù)，通過對堆、棧、共享庫映射等線性區(qū)布局的隨機化，通過增加攻擊者預(yù)測目的地址的難度，防止攻擊者直接定位攻擊代碼位置，達到阻止溢出攻擊的目的。通常情況下，黑客會利用某個特定函數(shù)或庫駐存在特定內(nèi)存位置的這一事實，通過在操縱堆或其他內(nèi)存錯誤時調(diào)用該函數(shù)來發(fā)動攻擊。ASLR則能夠避免這種情況，因為它能確保系統(tǒng)和應(yīng)用程序的代碼每次被加載時不會出現(xiàn)在同一個存儲位置。蘋果的iOS系統(tǒng)自iOS 4.3以后就支持ASLR技術(shù)；雖然Comex在7月份發(fā)布的“iPhone越獄”軟件就已攻克這一防御措施。而Android已經(jīng)在4.0中應(yīng)用了ASLR技術(shù)。

據(jù)研究表明ASLR可以有效的降低緩沖區(qū)溢出攻擊的成功率，如今Linux、FreeBSD、Windows等主流操作系統(tǒng)都已采用了該技術(shù)。

2、緩沖區(qū)溢出攻擊原理

緩沖區(qū)溢出是一種非常普遍、非常危險的漏洞，在各種操作系統(tǒng)、應(yīng)用軟件中廣泛存在。利用緩沖區(qū)溢出攻擊，可以導(dǎo)致程序運行失敗、系統(tǒng)宕機、重新啟動等后果。更為嚴重的是，可以利用它執(zhí)行非授權(quán)指令，甚至可以取得系統(tǒng)特權(quán)，進而進行各種非法操作。

緩沖區(qū)溢出（圖1）是指當(dāng)計算機向緩沖區(qū)內(nèi)填充數(shù)據(jù)位數(shù)時超過了緩沖區(qū)本身的容量溢出的數(shù)據(jù)覆蓋在合法數(shù)據(jù)上，理想的情況是程序檢查數(shù)據(jù)長度并不允許輸入超過緩沖區(qū)長度的字符,但是絕大多數(shù)程序都會假設(shè)數(shù)據(jù)長度總是與所分配的儲存空間相匹配,這就為緩沖區(qū)溢出埋下隱患.操作系統(tǒng)所使用的緩沖區(qū) 又被稱為"堆棧". 在各個操作進程之間,指令會被臨時儲存在"堆棧"當(dāng)中,"堆棧"也會出現(xiàn)緩沖區(qū)溢出。

在當(dāng)前網(wǎng)絡(luò)與分布式系統(tǒng)安全中，被廣泛利用的50%以上都是緩沖區(qū)溢出，其中最著名的例子是1988年利用fingerd漏洞的蠕蟲。而緩沖區(qū)溢出中，最為危險的是堆棧溢出，因為入侵者可以利用堆棧溢出，在函數(shù)返回時改變返回程序的地址，讓其跳轉(zhuǎn)到任意地址，帶來的危害一種是程序崩潰導(dǎo)致拒絕服務(wù)，另外一種就是跳轉(zhuǎn)并且執(zhí)行一段惡意代碼，比如得到shell，然后為所欲為。

歷史上最著名的緩沖區(qū)溢出攻擊可能要算是1988年11月2日的Morris Worm所攜帶的攻擊代碼了。這個因特網(wǎng)蠕蟲利用了fingerd程序的緩沖區(qū)溢出漏洞，給用戶帶來了很大危害。此后，越來越多的緩沖區(qū)溢出漏洞被發(fā)現(xiàn)。從bind、wu-ftpd、telnetd、apache等常用服務(wù)程序，到Microsoft、Oracle等軟件廠商提供的應(yīng)用程序，都存在著似乎永遠也彌補不完的緩沖區(qū)溢出漏洞。

圖1  緩沖區(qū)溢出攻擊示意

3、應(yīng)用ASLR后的一個簡單對比例子

下面使用一個比較典型的例子來顯示使用ASLR前后的效果：

C源代碼：

#include <stdlib.h>  
#include <unistd.h>  
main()  
 {  
     char *i;  
     char buff[20];  
    i=malloc(20);  
     sleep(1000);  
     free(i);  
 }  
#ps -aux|grep test  
 Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html  
 aslr_test        8731  0.0  0.0   1632   332 pts/0    S+   18:49   0:00 ./test  
 aslr_test        8766  0.0  0.0   2884   748 pts/1    R+   18:49   0:00 grep test  
 aslr_test@aslr_test-laptop:~$ cat /proc/8731/maps  
 08048000-08049000 r-xp 00000000 08:01 2256782    /home/aslr_test/Desktop/test  
 08049000-0804a000 rw-p 00000000 08:01 2256782    /home/aslr_test/Desktop/test  
 0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]  
 b7e60000-b7e61000 rw-p b7e60000 00:00 0  
 b7e61000-b7f9c000 r-xp 00000000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
 b7f9c000-b7f9d000 r--p 0013b000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
 b7f9d000-b7f9f000 rw-p 0013c000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
 b7f9f000-b7fa2000 rw-p b7f9f000 00:00 0  
 b7fae000-b7fb0000 rw-p b7fae000 00:00 0  
 b7fb0000-b7fc9000 r-xp 00000000 08:01 12195      /lib/ld-2.5.so  
 b7fc9000-b7fcb000 rw-p 00019000 08:01 12195      /lib/ld-2.5.so  
 bfe86000-bfe9c000 rw-p bfe86000 00:00 0          [stack]  
 ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]  
#ps -aux|grep test  
 Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html  
 aslr_test        8781  0.0  0.0   1632   332 pts/0    S+   18:49   0:00 ./test  
 aslr_test        8785  0.0  0.0   2884   748 pts/1    R+   18:49   0:00 grep test  
 aslr_test@aslr_test-laptop:~$ cat /proc/8781/maps  
 08048000-08049000 r-xp 00000000 08:01 2256782    /home/aslr_test/Desktop/test  
 08049000-0804a000 rw-p 00000000 08:01 2256782    /home/aslr_test/Desktop/test  
 0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]  
 b7e1e000-b7e1f000 rw-p b7e1e000 00:00 0  
 b7e1f000-b7f5a000 r-xp 00000000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
 b7f5a000-b7f5b000 r--p 0013b000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
 b7f5b000-b7f5d000 rw-p 0013c000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
 b7f5d000-b7f60000 rw-p b7f5d000 00:00 0  
 b7f6c000-b7f6e000 rw-p b7f6c000 00:00 0  
 b7f6e000-b7f87000 r-xp 00000000 08:01 12195      /lib/ld-2.5.so  
 b7f87000-b7f89000 rw-p 00019000 08:01 12195      /lib/ld-2.5.so  
 bfe23000-bfe39000 rw-p bfe23000 00:00 0          [stack]  
 ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]  

通過兩次運行后對比/proc下的進程信息可以發(fā)現(xiàn)進程棧和共享庫映射的地址空間都有了較大的變化，這使得以往通過esp值來猜測shellcode地址的成功率大大降低了。Phrack59期有一篇文章介紹過使用return-into-libc的方法突破ASLR保護，不過存在著較大的條件限制，milw0rm的一篇文章也介紹了通過搜索linux-gate.so.1中的jmp %esp指令從而轉(zhuǎn)向執(zhí)行shellcode的方法，不過由于現(xiàn)在的編譯器將要恢復(fù)的esp值保存在棧中，因此也不能繼續(xù)使用。總的來說，ASLR技術(shù)能夠很好地保證Android代碼及運行安全。