一定程度上能防范缓冲区溢出攻击的措施有哪些_缓冲溢出_图解 溢出攻击

复制积压缓冲内存：用于主从复制的部分复制，所有客户端共享该缓冲区，默认1mb，可通过repl-backlog-size调整，适当调大，可有效避免全量复制。一个oracle例程的系统全局区域(sga)包含几个内存区域(包括缓冲高速缓存、共享池、java 池、大型池和重做日志缓冲)。memoryfile是android在最开始就引入的一套框架，其内部实际上是封装了android特有的内存共享机制匿名共享内存，简单来说，ashmem在android内核中是被注册成一个特殊的字符设备，ashmem驱动通过在内核的一个自定义slab缓冲区中初始化一段内存区域，然后通过mmap把申请的内存映射到用户的进程空间中（通过tmpfs），这样子就可以在用户进程中使用这里申请的内存了，另外，ashmem的一个特性就是可以在系统内存不足的时候，回收掉被标记为”unpin”的内存，这个后面会讲到，另外，memoryfile也可以通过binder跨进程调用来让两个进程共享一段内存区域。

  char* source = "A reasonably long string";

  char dest[10];

  ::strcpy(dest, source);

所以，上面的声明1和声明2是等价的，它们都提示a是一个数组，也就是一个内存地址，数组内的字符可以从这个地址找到，编译器并不需要知道数组总共有多长，因为它只产生偏离起始地址的偏移地址，从数组提取一个字符，只要简单地从符号表显示的a的地址加上下标，需要的字符就位于这个地址中，但是，声明3告诉编译器a是一个指针，在32位的机器里它是个四字节的对象，它指向的对象是一个字符，为了取得这个字符，必须得到地址a的内容，把它作为字符的地址并从这个地址中取得字符，指针的访问要灵活的多，但需要增加一次额外的提取。堆栈stack 堆栈位于常规 ram 随机访问存储器 内 但可通过它的 堆栈指针 获得处理器的直接支持 堆栈指针若向下移会创建新的内存 若向上移 则会释放那些内存这是一种特别快 特别有效的数据保存方式 仅次于寄存器 创建程序时java编译器必须准确地知道堆栈内保存的所有数据的 长度 以及 存在时间 这是由于它必须生成相应的代码 以便向上和向下移动指针这一限制无疑影响了程序的灵活性 所以尽管有些 java数据要保存在堆栈里 特别是对象引用 但 java 对象并不放到其中。内存崩溃是内存使用最严重的结果，主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。

  当在C/C++中调用一个函数时，调用函数的返回地址被存放在堆栈中，因此在被调用函数执行完毕时，执行流程能重新返回到原处。如果调用了一个可能包含潜在缓冲区溢出的函数，返回地址可能会被修改，而且执行流程将会跳到缓冲区数据中指定的地方。通过改变函数的返回地址，攻击者可获取进程中任意位置的代码以执行，一般而言，主要可以两种方式被利用：

  ·如果带有漏洞的程序是已知、且容易访问到的，攻击者可查找某函数的地址，这通常会在所有进程实例的一处固定地址处被找到；并修改堆栈，等着此函数被调用。

  ·要执行的指令可作为缓冲区的一部分传递到进程地址空间，攻击者利用此来完成攻击。

  防范缓冲区溢出

  防范缓冲区溢出最简单的方式是限制复制的数据大小，使其不能大于目标缓冲区容量。虽然此方法看上去微不足道，但实际上，经验证明，要在那些大型的C/C++代码中，完全消除了缓冲区溢出的隐患，是件非常艰巨的任务。另外，使用如 .NET或Java这样的受托管技术，也能极大地降低缓冲区溢出的危险，但把大型项目移植到此技术上，实施起来不太可能也不适当。

当检测到异常时，我们调用exceptiondescribe函数打印这个异常的堆栈信息，然后再调用exceptionclear函数清除异常堆栈信息的缓冲区（如果不清除，后面调用thrownew抛出的异常堆栈信息会覆盖前面的异常信息），最后调用thrownew函数手动抛出一个java.lang.exception异常。 print "我是被装饰的函数"decorated_function = new_decorator(decorated_function)#输出:#我是装饰器，当你装饰一个函数式，我就被执行#作为装饰器一定程度上能防范缓冲区溢出攻击的措施有哪些，我将返回包装器函数print(1)#调用被装饰的函数decorated_function()#输出:#我是包装被装饰函数的包装器，当被装饰函数调用时，我也被执行作为包装器，我的职责是将被装饰的函数结果返回#我是被装饰的函数。既然我们知道了unhandledexceptionfilter在当前堆栈上被调用了，通过参考reactos的代码，我们会知道，这个函数带有异常信息，我们能不能通过这个异常信息了解到相关崩溃的位置呢。

  void _cdecl sec_handler( int code, void *)

  {

  if ( code == _SECERR_BUFFER_OVERRUN )

  {

  printf("检测到一个缓冲区溢出。\n");

  exit(1);

  }

  }

  int main()

  {

  _set_security_error_handler( sec_handler );

  //主程序代码在此省略。

  }

  Visual C++.NET 2003（7.1）通过移动易受攻击的数据结构--（如异常处理方法的地址）--到堆栈中位于缓冲区之下的某个位置，增强了缓冲区溢出的保护力度。在编译器的7.0版本中，可通过破坏缓冲区与cookie之间的敏感数据，绕过安全cookie所提供的保护；然而，在新版本的编译器中一定程度上能防范缓冲区溢出攻击的措施有哪些，已把这些数据移到位于缓冲区下的一个区域，现在，想要通过修改这些数据而达到溢出，似乎是不太可能了。

对于分配在堆栈上的局部变量来说，操作系统维护着一个堆栈指针来指向下一个自由空间的地址，并且堆栈的内存地址是由高位到低位向下填充，也就表示入栈时栈顶向低地址扩展，出栈时，栈顶向高地址回退以下例而言：。原理：aslr（地址空间布局随机化）技术的主要功能是通过对系统关键地址的随机化，防止攻击者在堆栈溢出后利用固定的地址定位到恶意代码并加以运行。堆栈段是一块动态内存区域，向下增长，也就是朝着低地址的方向增长，由系统维护，实现了一种后进先出的结构，运行时系统维护一个位于寄存器的堆栈指针sp，用于提示堆栈当前的顶部位置。

  除了把异常处理方法等信息移到堆栈中数据缓冲区之下，Visual C++.NET 2003的链接器也把结构化异常处理方法的地址放到可执行文件的头部中。当异常发生时，操作系统可以检查堆栈中的异常信息地址，是否符合记录在文件头信息中的异常处理方法，如果情况不符，异常处理方法将不会执行。比如说，Windows Server 2003就可检查结构化异常信息，而此项技术也在Service Pack 2中移植到了Windows XP上。

  而Visual C++ 2005（8.0）在此基础上又更进了一步，通常当有函数调用发生时，如果其中的一个本地缓冲区超出限度了，攻击者可能改写堆栈中在此之上的任何东西，包括异常处理、安全cookie、帧指针、返回地址和函数参数。而这些值的大多数被不同的机制所保护（如安全异常处理），但对一个有函数指针作参数的函数来说，仍有机会被溢出。如果一个函数接受一个函数指针（或结构、类中包含有函数指针）作为参数，攻击者就有可能改写指针中的值，使代码执行任何他想要的函数。鉴于此，Visual C++ 2005编译器将分析所有可能存在此漏洞的函数参数，并复制一份函数参数--并不使用原有的函数参数，把它放在堆栈中本地变量之下。如果原有函数参数被溢出改写了，只要副本中的值仍保持不变，整个函数就不会被攻破。

  应用缓冲区保护

  只需简单地打开/GS编译器开关，就可启用缓冲区保护。在Visual Studio中，此开关可在"C/C++"选项页的"代码生成"选项中找到。默认情况下，在Debug配置下为关，而在Release配置下为开。

  如果用最新版本的编译器进行编译，并生成结构化异常信息，那么在默认情况下，安全结构化异常处理将是打开的，另外，也可以使用/SAFESEH:NO命令行选项来关闭安全结构化异常处理，在Visual Studio的工程设置中，是没办法关闭安全结构化异常处理的，但仍可在链接器中使用此命令行选项来完成。

  /GS及更远的安全前景

按照这种原理进行的黑客入侵就叫做“堆栈溢出攻击”，我们不妨打个比方，黑客就获取了程序的控制权，就会覆盖其他数据区,再根据漏洞编写溢出程序(好多都自带扫描功能)包括本地提权溢出。与之前我们披露的漏洞不同，该漏洞溢出的位置非常精妙，可以轻易使黑客控制代码流程，是一枚上等的安全漏洞。想知道网站是否被挂马，可以有效降低被挂马的几率，通常就是黑客利用网站程序或者是语言脚本解释的漏洞上传一些可以直接对站点文件进行修改的脚本木马，直接检查每个脚本文件最下方是否被加入了iframe或者script的代码，然后通过web形式去访问那个脚本木马来实现对当前的网站文件进行修改.以上这些也是平时工作中经常遇到的问题，这需要有安全意识的程序员才能修复得了，有一个比较简单的方法.希望我的回答对你有所帮助，国内也就sinesafe和绿盟等安全公司 比较，“是否允许脚本”，程序员一看就能够知道、“写”，使用经营已久的虚拟空间提供商的空间，通常是在出现被挂马以后才知道要针对哪方面入手修复：。

  在Microsoft正式的术语中，/GS和SAGESEH均为软件强制的数据执行保护（DEP），软件强制的DEP也能以硬件的方式实现，如在实现了此功能的CPU中，如果数据出现在被标记为"不可执行"的内存页中，将不会执行它。Windows XP SP2及Windows Server 2003现在已支持这些技术，目前市面上的大多数的32位CPU及全部的64位CPU，都支持No Execute（NX）这类安全增强技术。

  任何一个好的安全系统，均有多层防范措施应对安全威胁。本文所涉及的编译器开关，它能防范或减少普通编码错误所带来的安全隐患，而且它具有易于使用和低成本的特点，在这场没有硝烟的战争中，不失为一个好的解决方案，绝对值得你的程序采用。

分享到:

0

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-115083-1.html