【專家專欄】Android中的防緩衝區溢位技術

BKJIA專稿】本文將詳細介紹Android中的防緩衝區溢位技術的來龍去脈。

1、什麼是ASLR？

ASLRAddress space layout randomization）是一種針對緩衝區溢位的安全保護技術，通過對堆、棧、共用庫映射等線性區布局的隨機化，通過增加攻擊者預測目的地址的難度，防止攻擊者直接定位攻擊代碼位置，達到阻止溢出攻擊的目的。通常情況下，駭客會利用某個特定函數或庫駐存在特定記憶體位置的這一事實，通過在操縱堆或其他記憶體錯誤時調用該函數來發動攻擊。ASLR則能夠避免這種情況，因為它能確保系統和應用程式的代碼每次被載入時不會出現在同一個儲存位置。蘋果的iOS系統自iOS 4.3以後就支援ASLR技術；雖然Comex在7月份發布的“iPhone越獄”軟體就已攻克這一防禦措施。而Android已經在4.0中應用了ASLR技術。

據研究表明ASLR可以有效降低緩衝區溢位攻擊的成功率，如今Linux、FreeBSD、Windows等主流作業系統都已採用了該技術。

2、緩衝區溢位攻擊原理

緩衝區溢位是一種非常普遍、非常危險的漏洞，在各種作業系統、應用軟體中廣泛存在。利用緩衝區溢位攻擊，可以導致程式運行失敗、系統宕機、重新啟動等後果。更為嚴重的是，可以利用它執行非授權指令，甚至可以取得系統特權，進而進行各種非法操作。

緩衝區溢位圖1）是指當電腦向緩衝區內填充資料位元數時超過了緩衝區本身的容量溢出的資料覆蓋在合法資料上，理想的情況是程式檢查資料長度並不允許輸入超過緩衝區長度的字元,但是絕大多數程式都會假設資料長度總是與所分配的儲存空間相匹配,這就為緩衝區溢位埋下隱患.作業系統所使用的緩衝區 又被稱為"堆棧". 在各個操作進程之間,指令會被臨時儲存在"堆棧"當中,"堆棧"也會出現緩衝區溢位。

在當前網路與分布式系統安全中，被廣泛利用的50%以上都是緩衝區溢位，其中最著名的例子是1988年利用fingerd漏洞的蠕蟲。而緩衝區溢位中，最為危險的是堆疊溢位，因為入侵者可以利用堆疊溢位，在函數返回時改變返回程式的地址，讓其跳轉到任意地址，帶來的危害一種是程式崩潰導致拒絕服務，另外一種就是跳轉並且執行一段惡意代碼，比如得到shell，然後為所欲為。

曆史上最著名的緩衝區溢位攻擊可能要算是1988年11月2日的Morris Worm所攜帶的攻擊代碼了。這個網際網路蠕蟲利用了fingerd程式的緩衝區溢位漏洞，給使用者帶來了很大危害。此後，越來越多的緩衝區溢位漏洞被發現。從bind、wu-ftpd、telnetd、apache等常用服務程式，到Microsoft、Oracle等軟體廠商提供的應用程式，都存在著似乎永遠也彌補不完的緩衝區溢位漏洞。

圖1  緩衝區溢位攻擊示意

3、應用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下的進程資訊可以發現進程棧和共用庫映射的地址空間都有了較大的變化，這使得以往通過esp值來猜測shellcode地址的成功率大大降低了。Phrack59期有一篇文章介紹過使用return-into-libc的方法突破ASLR保護，不過存在著較大的條件限制，milw0rm的一篇文章也介紹了通過搜尋linux-gate.so.1中的jmp %esp指令從而轉向執行shellcode的方法，不過由於現在的編譯器將要恢複的esp值儲存在棧中，因此也不能繼續使用。總的來說，ASLR技術能夠很好地保證Android代碼及運行安全。