初遇缓冲区溢出攻击

初遇缓冲区溢出(Stack Buffer Overflow)攻击

那天晚上，某种业务有好几个服务端进程在短时间内崩溃了。

同事上去看了，发现都是在处理来自同一个地方东莞的同一个IP地址过来的请求时发生core dump。

恩，诡异，当时我们先跟运维同事联系，在该业务的几个服务器上 临时紧急禁掉该IP的连接。

我也上去看了，用GDB查看core文件。看了trace back基本上知道，都是在处理某个类型的消息请求时出的问题。再查看了一下当时的一些临时变量，然后明白了。

接收到客户端发来的这种类型的请求消息后，进入处理函数。 服务端会根据请求消息中的一个字段 ，做某种计算，计算的结果放到一个函数中声明的长度为100的数组。

计算的结果的长度和请求消息中的字段的长度有关，请求消息中的数据越长，计算结果越长。

调试器中显示，当时计算结果有576个字节，显然长度为100字节的数组装不下(正常客户端发的都不会超过这个长度), 导致栈空间被胡写.... 

这不就是经常听说的缓冲区溢出攻击吗？ 只要它重写了该函数本次调用的返回地址，就可以返回后执行攻击者的代码。而服务端进程基本都以root权限运行，所以这样攻击者可以做很多事情。

不过还好，正因为缓冲区溢出很经典，C/C++先驱们也有了一些对策。GCC编译器做了Stack-Smashing Protector 机制，在单字节数组后插入一些金丝雀(Canary, 因为大家在矿井作业时，会用金丝雀来预警，如果金丝雀死了，那证明有毒气)，如果canary被改掉，在函数执行完成返回之前会检查一下Canary，发现被篡改则不再继续执行，中止程序，避免执行攻击者的代码。

所以我们的程序出现这个log：

“*** stack smashing detected ***

并且进程崩溃掉了，证明GCC的保护起作用了。缓冲区溢出攻击没有得逞。

GCC编译器的Stack-Smashing Protector 机制由编译选项-fstack-protector(或-fstack-protector-all)来开启，在那之前我们并没有刻意增加这个编译选项，幸好Ubuntu linux默认是打开-fstack-protector选项的。

http://soc.if.usp.br/doc/gcc-4.1-doc/gcc.html：

 On Ubuntu the default is -fstack-protector, to turn it off use -fno-stack-protector. 

事后，增加简单的长度检查就可以修复这个问题。因为这个代码来自服务区比较公用的一个基本库，所以我猜测其他和客户端直接连接的服务端进程也存在类似问题。虽然邮件抄送给大佬，不过没引起重视，不久之后其他组果然也发现类似问题.....

其实，平时在代码中有访问数组的地方，可以多考虑边界检查，从编程规范上预防类似问题。

-------------------------------------------------------------------------------------------------

更多博文请订阅RSS，更多微博请关注@千里孤行Nerd