Android中的防缓冲区溢出技术

Android系统提供了非常严格的多层次的安全保护措施，包括代码。为了防止恶意用户采用恶意软件进行缓冲区溢出***或者进行“越狱”操作，自Android 4.0版本之后，内核就引入了ASLR技术来对代码进行保护，本文将详细介绍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源代码：

#include
#include
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代码及运行安全。