1. 程式人生 > >如何處理Android中的防緩沖區溢出技術

如何處理Android中的防緩沖區溢出技術

libc 針對 div padding border gin 圖1 netd stdlib.h

【51CTO專稿】本文將具體介紹Android中的防緩沖區溢出技術的來龍去脈。

1、什麽是ASLR?

ASLR(Address 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源碼:

  1. #include <stdlib.h>
  2. #include <unistd.h>
  3. main()
  4. {
  5. char *i;
  6. char buff[20];
  7. i=malloc(20);
  8. sleep(1000);
  9. free(i);
  10. }
  11. #ps -aux|grep test
  12. Warning: bad ps syntax, perhaps a bogus ‘-‘? See http://procps.sf.net/faq.html
  13. aslr_test 8731 0.0 0.0 1632 332 pts/0 S+ 18:49 0:00 ./test
  14. aslr_test 8766 0.0 0.0 2884 748 pts/1 R+ 18:49 0:00 grep test
  15. [email protected]_test-laptop:~$ cat /proc/8731/maps
  16. 08048000-08049000 r-xp 00000000 08:01 2256782 /home/aslr_test/Desktop/test
  17. 08049000-0804a000 rw-p 00000000 08:01 2256782 /home/aslr_test/Desktop/test
  18. 0804a000-0806b000 rw-p 0804a000 00:00 0 [heap]
  19. b7e60000-b7e61000 rw-p b7e60000 00:00 0
  20. b7e61000-b7f9c000 r-xp 00000000 08:01 12116 /lib/tls/i686/cmov/libc-2.5.so
  21. b7f9c000-b7f9d000 r--p 0013b000 08:01 12116 /lib/tls/i686/cmov/libc-2.5.so
  22. b7f9d000-b7f9f000 rw-p 0013c000 08:01 12116 /lib/tls/i686/cmov/libc-2.5.so
  23. b7f9f000-b7fa2000 rw-p b7f9f000 00:00 0
  24. b7fae000-b7fb0000 rw-p b7fae000 00:00 0
  25. b7fb0000-b7fc9000 r-xp 00000000 08:01 12195 /lib/ld-2.5.so
  26. b7fc9000-b7fcb000 rw-p 00019000 08:01 12195 /lib/ld-2.5.so
  27. bfe86000-bfe9c000 rw-p bfe86000 00:00 0 [stack]
  28. ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
  29. #ps -aux|grep test
  30. Warning: bad ps syntax, perhaps a bogus ‘-‘? See http://procps.sf.net/faq.html
  31. aslr_test 8781 0.0 0.0 1632 332 pts/0 S+ 18:49 0:00 ./test
  32. aslr_test 8785 0.0 0.0 2884 748 pts/1 R+ 18:49 0:00 grep test
  33. [email protected]_test-laptop:~$ cat /proc/8781/maps
  34. 08048000-08049000 r-xp 00000000 08:01 2256782 /home/aslr_test/Desktop/test
  35. 08049000-0804a000 rw-p 00000000 08:01 2256782 /home/aslr_test/Desktop/test
  36. 0804a000-0806b000 rw-p 0804a000 00:00 0 [heap]
  37. b7e1e000-b7e1f000 rw-p b7e1e000 00:00 0
  38. b7e1f000-b7f5a000 r-xp 00000000 08:01 12116 /lib/tls/i686/cmov/libc-2.5.so
  39. b7f5a000-b7f5b000 r--p 0013b000 08:01 12116 /lib/tls/i686/cmov/libc-2.5.so
  40. b7f5b000-b7f5d000 rw-p 0013c000 08:01 12116 /lib/tls/i686/cmov/libc-2.5.so
  41. b7f5d000-b7f60000 rw-p b7f5d000 00:00 0
  42. b7f6c000-b7f6e000 rw-p b7f6c000 00:00 0
  43. b7f6e000-b7f87000 r-xp 00000000 08:01 12195 /lib/ld-2.5.so
  44. b7f87000-b7f89000 rw-p 00019000 08:01 12195 /lib/ld-2.5.so
  45. bfe23000-bfe39000 rw-p bfe23000 00:00 0 [stack]
  46. 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代碼及執行安全。

如何處理Android中的防緩沖區溢出技術