怎样处理Android中的防缓冲区溢出技术

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

时间: 2024-10-08 20:50:46

怎样处理Android中的防缓冲区溢出技术的相关文章

如何处理Android中的防缓冲区溢出技术

[51CTO专稿]本文将具体介绍Android中的防缓冲区溢出技术的来龙去脉. 1.什么是ASLR? ASLR(Address space layout randomization)是一种针对缓冲区溢出的安全保护技术,通过对堆.栈.共享库映射等线性区布局的随机化.通过添加攻击者预測目的地址的难度.防止攻击者直接定位攻击代码位置,达到阻止溢出攻击的目的.通常情况下.黑客会利用某个特定函数或库驻存在特定内存位置的这一事实.通过在操纵堆或其它内存错误时调用该函数来发动攻击.ASLR则可以避免这样的情况

转:&quot;在已损坏了程序内部状态的XXX.exe 中发生了缓冲区溢出&quot;的一种可能原因

我的问题跟原作者的问题差不多.头文件和DLL不匹配导致的. 原文链接:http://blog.csdn.net/u012494876/article/details/39030887 今天软件突然出现崩溃的bug: 在release模式下,总是崩溃在一个函数A的结束处,打印输出调试,发现如果注释该函数A中的某个函数B的调用,崩溃不会发生:除此之外,注释函数B中的任何代码都不起作用. 崩溃时弹出的对话框为:"在已损坏了程序内部状态的 BREW_Simulator.exe 中发生了缓冲区溢出.按“中

Android中apk动态加载技术研究(2)android插件化及实现

了解了android中类加载的前期知识点后,来看看android中DexClassLoader具体的实现 具体加载流程如下: 宿主程序会到文件系统比如SD卡中去加载APK[1],然后通过一个叫proxy的Activity去执行apk中的Activity 关于动态加载ap,理论上可用用到DexClassLoad.PathClassLoader.URLClassLoader; DexClassLoader: 可以加载文件系统上的jar.dex.apk PathClassLoader:可以加载 /da

Android中apk动态加载技术研究(1)基础知识研修

java classloader 和android中DexClassloader对比: Java ClassLoader : 作用: 主要用来加载class 到jvm中,以供程序使用,也就是说:java程序可以动态加载类定义,而这个动态加载机制就是通过ClassLoader来实现的 核心loader: A:: bootstrap classloader(启动类加载器) -->加载java核心api,包括用户自定义的classloader和另外两个loader B: ExtClassLoader

Android中的跨进程调用技术AIDL

什么是AIDL Android系统中的进程之间不能共享内存,因此,需要提供一些机制在不同进程之间进行数据通信. 为了使其他的应用程序也可以访问本应用程序提供的服务,Android系统采用了远程过程调用(Remote Procedure Call,RPC)方式来实现. 与很多其他的基于RPC的解决方案一样,Android使用一种接口定义语言(Interface Definition Language,IDL)来公开服务的接口. Android的四大组件中的三个(Activity.Broadcast

缓冲区溢出攻击(待看)

缓冲区溢出攻击 本词条缺少信息栏.名片图,补充相关内容使词条更完整,还能快速升级,赶紧来编辑吧! 缓冲区溢出攻击是利用缓冲区溢出漏洞所进行的攻击行动.缓冲区溢出是一种非常普遍.非常危险的漏洞,在各种操作系统.应用软件中广泛存在.利用缓冲区溢出攻击,可以导致程序运行失败.系统关机.重新启动等后果. 1简介编辑 缓冲区溢出是指当计算机向缓冲区内填充数据位数时超过了缓冲区本身的容量,溢出的数据覆盖在合法数据上.理想的情况是:程序会检查数据长度,而且并不允许输入超过缓冲区长度的字符.但是绝大多数程序都会

SEED缓冲区溢出实验笔记

缓冲区溢出实验(Linux 32位) 参考教程与材料:http://www.cis.syr.edu/~wedu/seed/Labs_12.04/Software/Buffer_Overflow/ (本文记录了做SEED缓冲区溢出实验的体会与问题,侧重实践,而不是讲解缓冲区溢出原理的详细教程) 1. 准备工作 使用SEED ubuntu虚拟机进行缓冲区溢出实验,首先要关闭一些针对此攻击的防御机制来简化实验. (1)内存地址随机化(Address Space Randomization):基于Lin

Android中插件开发篇总结和概述

刚刚终于写完了插件开发的最后一篇文章,下面就来总结一下,关于Android中插件篇从去年的11月份就开始规划了,主要从三个方面去解读Android中插件开发原理.说白了,插件开发的原理就是:动态加载技术.但是我们在开发插件的过程中可能会遇到很多问题,所以这里就分为三篇文章进行解读的,而且也是循序渐进,解决了插件开发过程中可能会遇到的问题,不过这三篇的基础还是动态加载技术. 第一.插件开发基础篇:动态加载技术解读 http://blog.csdn.net/jiangwei0910410003/ar

查找并修复Android中的内存泄露—OutOfMemoryError

[编者按]本文作者为来自南非约翰内斯堡的女程序员 Rebecca Franks,Rebecca 热衷于安卓开发,拥有4年安卓应用开发经验.有点完美主义者,喜爱美食. 本文系国内ITOM管理平台 OneAPM 编译呈现,以下为正文. Android 程序中很容易出现内存泄露问题.毫无戒心的开发者可能每天都会造成一些内存泄露,却不自知.你可能从未注意过这类错误,或者甚至都不知道它们的存在.直到你遇到下面这样的异常: java.lang.OutOfMemoryError: Failed to allo